c# - framework - Asesoramiento sobre mapeo de entidades a objetos de dominio

ddd net core (3)

¿Por qué no simplemente usa entidades EF como objetos de Dominio ya que primero está buscando usar el código de Entity Framework 6 ? Así que primero diseñas modelo de dominio y luego estructura de base de datos.

He estado usando NHibernate y creo que en EF también puede especificar reglas de mapeo desde las tablas de DB a sus objetos POCO, especialmente con EF6. Es un esfuerzo adicional desarrollar otra capa de abstracción sobre las entidades EF. Deje que ORM sea responsable de ello.

No estoy de acuerdo con este artículo que podría leer "Entity Framework 5 con AutoMapper and Repository Pattern" y hay muchos otros artículos donde las personas simplemente usan entidades EF como objetos de dominio :

AutoMapper definitivamente lo ayudará cuando comience a construir la capa de presentación y se enfrentará a muchos modelos de vista específicos de UI. Es útil en la construcción de modelos anémicos y un poco inútil con objetos de Dominio reales cuando no hay instaladores públicos.

Hay una publicación anterior de Jimmy Bogard, "El caso del mapeo bidireccional en AutoMapper", donde dice que "There is no two-way mapping because we never need two-way mapping."

Entonces, ¿para qué estamos usando AutoMapper? Nuestros cinco perfiles incluyen:
De dominio a ViewModel (modelos de vista fuertemente tipados para MVC)
De dominio a EditModel (modelos de vista fuertemente tipados para formularios en MVC)
De EditModel a CommandMessages: yendo desde el modelo de edición poco tipeado a los mensajes fuertemente tipados y descompuestos. Un solo EditModel puede generar media docena de mensajes.
De dominio a modelo de informe: informes de Telerik fuertemente tipados
Desde el dominio al modelo EDI: modelos aplanados utilizados para generar informes EDI

Actualmente estoy trabajando en un proyecto en el que estamos empezando a crear una aplicación utilizando un enfoque DDD. Ahora estamos estudiando el uso del código de Entity Framework 6 para ayudarnos con la persistencia de los datos. Mi pregunta es cómo manejar mejor la asignación de datos entre nuestros objetos de dominio y las entidades EF.

Oh no, yo no añadiría esa capa extra en absoluto.

NHibernate y Entity Framework Code-First (usaría EF) están diseñados para resolver este problema exacto: asignar los objetos de su dominio a su modelo relacional (que no tienen las mismas limitaciones en su diseño, por lo que podría, y probablemente lo hará, ser una forma diferente).

Me parece una pena desperdiciar las excelentes capacidades de mapeo de EF y reemplazarlo con algo más, incluso AutoMapper.

Para mantener su aplicación y usted cuerdo a largo plazo, NUNCA JAMÁS inicie su aplicación DDD con problemas relacionados con la persistencia (qué db, qué orm, etc.) y SIEMPRE (sí, siempre) toque la base de datos como la última etapa del desarrollo.

Modele su dominio y, de hecho, cualquier otro modelo, excepto la persistencia. Use el patrón Repositorio para mantener la aplicación desacoplada de Persistence. Defina la interfaz repo según lo necesite la aplicación y no esté vinculada al método de acceso db (es por eso que está implementando la persistencia más tarde para que no tenga la tentación de vincular su aplicación a los detalles de persistencia).

Escribir implementaciones en memoria para las interfaces repo, esto generalmente significa un simple contenedor sobre una lista o diccionario, por lo que es MUY rápido de escribir y, lo que es más importante, es trivial de cambiar. Úselos para probar y desarrollar la aplicación.

Una vez que las interfaces son estables y la aplicación funciona, es hora de escribir la implementación de persistencia donde puede usar lo que desee. En su caso EF y ahí viene el mapeo.

Ahora, esto es altamente subjetivo, no hay una manera correcta o incorrecta, existe la forma en que USTED prefiere hacer las cosas.

Personalmente, tengo el hábito de usar los recuerdos para obtener el recuerdo del objeto de dominio y luego asignarlo manualmente a las entidades (micro) ORM. La razón por la que lo hago manualmente es porque mis recuerdos contienen objetos de valor. Si estuviera usando AutoMapper necesitaría confesurearlo y en esencia estaría escribiendo más código que hacerlo manualmente

Actualización (2015)

En estos días simplemente Json el objeto y, o bien uso un modelo de lectura específico o lo almacena directamente en un modelo de lectura con una columna de Data que contiene el objeto serializado. Uso Mementos solo para casos muy específicos. </ update>

Dependiendo de cómo se vean los objetos de su dominio y cómo se vean las entidades de EF, es posible que se salga con la tarea utilizando el automapper para la mayoría de los mapas. Sin embargo, le costará más probar sus repositorios.

Depende de usted cómo lo hace, encuentre la manera que se adapte a su estilo y sea fácil de mantener, pero NUNCA JAMÁS diseñar o modificar sus objetos de dominio para que sean más compatibles o para que coincidan con las entidades ORM. No se trata de cambiar bases de datos o ORM, se trata de tener el dominio (y el resto de la aplicación) desacoplado correctamente de los detalles de Persistencia (que es el ORM).

Así que resista la tentación de reutilizar cosas que son detalles de implementación de otras capas. La razón por la que la aplicación está estructurada en capas es porque quieres desacoplar. Déjalo de esa forma.