Entity Framework y evitar el modelo de dominio anémico

11

En nuestra lógica de negocios, ocasionalmente tenemos métodos definidos como estos:

User.ResetCourse(Course courseToReset)

El problema es que tanto el usuario como el curso son objetos proxy de Entity Framework. Esto significa que cuando accedemos a las propiedades de navegación en Usuario o Curso, puede causar un gran impacto en la base de datos porque esos objetos no son IQueryable, por lo que itera a través de ellos normalmente.

Para resolver esto, cambiamos la firma a:

User.ResetCourse(MyDBContext db, Course courseToReset)

Esto significa que podemos consultar directamente la base de datos para realizar los cambios que necesitamos de manera eficiente, pero pasar el contexto de la base de datos a un objeto de negocio parece tan incorrecto.

Más tarde migramos al usuario una capa de servicio, lo que significa que tenemos algo como:

CourseService.ResetForUser(Course courseToReset, User forUser)

Este servicio tiene una referencia al DBContext inyectado en la creación, pero ahora nuestros objetos comerciales son solo bolsas de datos sin comportamiento (es decir, un modelo de dominio anémico).

¿Cómo podemos evitar esto?

c# entity-framework domain-model business-logic

— Steve
fuente

11

Suena como si acabara de darse cuenta de que los modelos de marco de entidad son en realidad DTO, y no realmente un modelo de dominio. ¿De verdad estás intentando hacer DDD? Si no, probablemente no importa.

— Sr. Cochese

3

ADM plus services es una buena arquitectura para muchas cosas

— Ewan

1

Pertinente: ADM no es un antipatrón, es un diseño SÓLIDO .

— John Wu

2

@ JohnWu ese es un artículo muy parcial. De hecho, contiene una versión "Strawman" de un modelo de dominio rico, al incluir el patrón Active Record en el rico ejemplo. Ciertamente, Active Record no se adopta en DDD y, en general, es una mala elección para cualquier aplicación compleja.

— RibaldEddie

8

El problema es que, en primer lugar, está utilizando objetos EF como objetos de dominio. Los objetos EF son modelos de datos, NO modelos de negocios.

Debe declarar objetos comerciales que le den la libertad de hacer lo que necesite y luego recuperarlos y almacenarlos en un repositorio. Su repositorio asignará las entidades EF a sus entidades comerciales. Los objetos EF nunca deben usarse fuera de sus repositorios.

— TheCatWhisperer
fuente

0

Probablemente pueda evitarlo haciendo algo como:

CourseService.prepareForUserCourseReset(DBContext db);
User.reset();
Course.reset();
CourseService.completeUserCourseReset(DBContext db);

O algo por el estilo, de todos modos, si me entiendes. Parece que el enfoque que tiene con la forma inicial que describió está relacionado con el rendimiento y no necesariamente con la estructura del dominio. Entonces, realmente debería considerar resolver el problema de rendimiento en la capa de servicio, pero puede mantener el comportamiento en el dominio. Sería útil saber qué significa restablecer el usuario / curso en este contexto también si desea una mejor respuesta.

— RibaldEddie
fuente

-1

Tradicionalmente, esto se resuelve mediante el uso de una estrategia de recuperación para cada caso de uso que instruye a Entity Framework para que cargue ansiosamente las asociaciones necesarias en la consulta inicial usando IQueryable.Include ().

Udi Dahan escribió una publicación que describe el enfoque general, que se puede adaptar a Entity Framework.

http://udidahan.com/2007/09/16/fetching-strategy-nhibernate-implementation-available/

— pnschofield
fuente