ORM Entidades vs. Entidades de Dominio bajo Entity Framework 6.0

entity-framework domain-model

Question

Me encontré con los siguientes dos artículos First y Second en los que el autor afirma en resumen que las Entidades de ORM y las Entidades de Dominio no deberían mezclarse.

Me enfrento exactamente a este problema en este momento cuando codigo con EF 6.0 usando el enfoque Code First. Utilizo las clases de POCO como entidades en el EF, así como en mi dominio / objetos comerciales. Pero me encuentro frecuentemente en la situación en la que defino una propiedad como pública o una propiedad de navegación como virtual solo porque el Marco EF me obliga a hacerlo.

No sé qué tomar como el resultado final de los dos artículos? ¿Debería crear realmente, por ejemplo, una clase CustomerEF para el marco de entidades y un CustomerD para mi dominio? A continuación, cree un repositorio que consuma CustomerD lo asigne al ClienteEF realice algunas consultas y luego vuelva a asignar el CustomerEF recibido a CustomerD. Pensé que EF se trata de mapear mis entidades de dominio a los datos.

Entonces por favor dame un consejo. ¿Debo pasar por alto algo importante que el EF puede proporcionarme? ¿O es este un problema que no puede resolverse por completo por EF? En el último caso, ¿cuál es una buena forma de manejar este problema?

Answer 1

Estoy de acuerdo con la idea general de estas publicaciones. Un modelo de clase ORM es, en primer lugar, parte de una capa de acceso a datos (incluso si consta de los denominados POCO). Si surge un conflicto de intereses entre la persistencia y la lógica comercial (o cualquier otra preocupación), las decisiones siempre deberían tomarse a favor de la persistencia.

Sin embargo, como desarrolladores de software siempre tenemos que equilibrar el purismo y el pragmatismo. El uso o no del modelo de persistencia como modelo de dominio depende de varios factores:

• El tamaño / coherencia del equipo de desarrollo. Cuando todo el equipo sabe que las propiedades pueden ser públicas solo por los requisitos de ORM, pero no deben establecerse en cualquier lugar, puede no ser un gran problema. Si todos saben (y obedecen) que una propiedad de ID no se debe usar en la lógica de negocios, tener IDs puede no ser un gran problema. Un equipo disperso, inexperto o indisciplinado puede necesitar una segregación de código más estricta.

• La superposición entre preocupaciones de lógica de negocios y preocupaciones de persistencia. El diseño orientado a objetos prospera cuando un modelo de clase se apega a los principios SOLID . Pero estos principios no están necesariamente en desacuerdo con las preocupaciones de persistencia. Quiero decir que aunque las preocupaciones son diferentes, al final sus requisitos resultantes pueden ser bastante similares. Por ejemplo, ambas preocupaciones pueden requerir un estado de objeto válido y asociaciones correctas.

  Sin embargo, puede haber casos de uso en los que los objetos necesitan estar temporalmente en un estado que no debe almacenarse. Esta puede ser una razón para trabajar con clases de dominio dedicadas. Otra razón puede ser que el modelo de la entidad simplemente no puede cumplir con la mejor segmentación de responsabilidades. Por ejemplo, un proceso de negocio "cliente de la lista negra" puede requerir datos dispersos en tantos objetos de entidad que deben diseñarse nuevas clases de dominio que pueden encapsular los datos y los métodos que trabajan en ellos. En otras palabras: hacer esto por las entidades violaría el principio de No preguntar .

• La necesidad de capas. Por ejemplo, si la capa de acceso a datos se dirige a diferentes proveedores de bases de datos, puede consistir en partes intercambiables que sean específicas del proveedor (por ejemplo, para detectar diferencias sutiles en tipos de datos entre Oracle y Sql Server o para explotar características específicas del proveedor). El uso del modelo de persistencia como modelo de dominio probablemente afecte las implementaciones específicas del proveedor en la lógica comercial. Eso sería realmente malo. Allí, la capa de acceso a los datos debería ser precisamente eso, una capa.

• (Muy trivial) La cantidad de datos. Crear objetos requiere tiempo y recursos. Cuando "muchos" objetos están involucrados en un caso de negocios, puede ser demasiado costoso construir tanto objetos de entidad como objetos de dominio.

Y más, sin dudas.

Entonces siempre trataría de ser un pragmático. Si las clases de entidades hacen un trabajo decente, ve por ello. Si la discrepancia es demasiado grande, cree un dominio comercial para las partes apropiadas de la lógica comercial. No seguiría servilmente un (cualquiera) patrón de diseño solo porque es un buen patrón. Al contrario de lo que se dice en la publicación, requiere mucho mantenimiento para mapear un modelo de entidad en un modelo de negocio. Cuando te encuentras creando miles de clases de negocios que son casi idénticas a las clases de entidades, es hora de reconsiderar lo que estás haciendo.