c# - mapeo - ORM/¿Cómo tratar la correspondencia entre el objeto de Dominio y el objeto persistente?

orm java

Question

En una aplicación, hay al menos dos formas de tratar con la persistencia de objetos de dominio y un ORM.

• Mapeo directo del objeto de dominio a la persistencia utilizando algún tipo de ORM (xml o anotaciones)
• Haciendo la separación de las preocupaciones en caso de una gran cantidad de desajuste de impedancias entre su dominio y su modelo persistente (columnas de la tabla). Esto significa que el objeto de dominio es independiente de la persistencia y hay algunas conversiones a algún objeto persistente correspondiente, este último se correlaciona con un ORM.

Como saben los desarrolladores puros de DDD, el dominio no debe ser impulsado por las necesidades de su base de datos, por lo tanto, en mi proyecto, utilizo esta separación de preocupaciones. Alguien pensaría en YAGNI, alguien diría "genial" (como aquí ). Mi proyecto necesitará algunas bases de datos diferentes según mi necesidad de reutilización, así que elegí la separación de las preocupaciones entre mi modelo de dominio y mi modelo persistente. Pero me encontré con un problema (algún tipo de pérdida de rendimiento), con Spring-Data. Un detalle tal vez, pero solo asuma un ORM que no tenga la funcionalidad de merge , o algo relacionado, para volver a conectar entidades separadas a la transacción actual.

Para entender, supongamos que este código conceptual (en Java):

@Transaction
public void participateToMeeting(String userId, String meetingId){
  User user = userRepository.ofId(userId);  //returns a User domain type
  Meeting meeting = meetingRepository.ofId(meetingId); //returns a Meeting domain type
  if(user != null && meeting != null) {
    user.participate(meeting);    // as attached entity, this would automatically persist the relationship
  }
}

Pero si de ahora en adelante, la persistencia ocurre en el modelo persistente, no directamente en el modelo de dominio, perderíamos el adjunto, ya que durante la conversión de dominio a objeto persistente (de hecho, los repositorios ahora tratarían con objetos persistentes (en lugar del modelo de dominio directamente) y simplemente convierte el resultado como objeto de dominio como tipo de devolución), se managedEntity estado managedEntity .

    @Transaction
        public void participateToMeeting(String userId, String meetingId){
          User user = userRepository.ofId(userId);  //returns a User domain type (converted from UserPO to User)
          Meeting meeting = meetingRepository.ofId(meetingId); //returns a Meeting domain type (converted from MeetingPO to UserPO)
          if(user != null && meeting != null) {
            userRepository.participateToMeeting(user, meeting); 
//although not conventional, adding this kind of method allows to convert User and Meeting to some persistent object: UserPO and MeetingPO, before proceeding to persistence
          }
        }

Aquí está el problema: Al convertir de User a UserPO (en mi capa de infraestructura ), pierdo el "archivo adjunto" de la entidad. Por lo tanto, en el método userRepository.participateToMeeting , tengo que recuperar UserPO y MeetingPO nuevamente de la base de datos (para hacerlos adjuntos) ... por lo tanto, implican dos solicitudes adicionales.

¿Existe una mejor práctica para tratar con objeto de dominio de conversión / objeto persistente sin esta pérdida de rendimiento?

Answer 1

No estoy de acuerdo con el artículo vinculado. Si bien estoy de acuerdo en que las preocupaciones entre el modelo de dominio y el modelo de persistencia son diferentes, el propósito completo de un ORM es hacer un mapeo entre un modelo de dominio y un modelo de persistencia. Como se supone que el ORM proporciona esa asignación, la creación de una jerarquía de clases adicional para facilitar el mapeo es excesiva y puede generar problemas como el que está describiendo. El hecho de que el modelo de dominio se asemeje al modelo de datos es mucho más que una mera coincidencia. En cambio, ambos representan aspectos del mismo dominio y, por lo tanto, deben tener un alto grado de correspondencia. El ORM está diseñado para abordar la falta de coincidencia entre un modelo de objeto y un modelo relacional correspondiente. Hay casos en los que el mapeo se vuelve difícil, pero en NHibernate, por ejemplo, estos pueden abordarse mediante la implementación de tipos de usuario personalizados para las asignaciones de componentes.