Cómo lidiar con DDD y EF4

Question

Tengo varios problemas al tratar de aplicar DDD con EF4 (en contexto ASP MVC2). Su ventaja sería muy apreciada.

En primer lugar, comencé a utilizar POCO porque la dependencia de ObjectContext no era muy cómoda en muchas situaciones.

Ir a POCO resolvió algunos problemas, pero la experiencia no es la que estaba acostumbrado con NHibernate.

Me gustaría saber si es posible usar el diseñador y generar no solo entidades sino también un objeto de valor (¿Tipo complejo?). Si me refiero a Value Object es una clase con un ctor sin propiedades establecidas (¿se necesita una modificación T4?).

La única forma que he encontrado de agregar comportamiento a entidades anémicas es crear clases parciales que amplíen las generadas por edmx. No estoy satisfecho con este enfoque.

No sé cómo crear varios repositorios con un solo edmx. Por ahora estoy usando un método de clases parciales a grupales para cada agregado. Cada grupo es un repositorio de hecho.

La última pregunta es sobre IQueryable. ¿Debería estar expuesto fuera del repositorio? Si me refiero al libro ble, el repositorio debe ser una unidad de ejecución y no debe exponer algo como IQueryable. Qué piensas ?

Gracias por su ayuda.

Thomas

Answer 1

Ha pasado un tiempo desde que hice esa pregunta y tuve la oportunidad de hacerlo por mi cuenta.

No creo que sea una buena práctica exponer IQueryable fuera de la capa DAL. Trae más problemas que soluciona. Estoy hablando de grandes aplicaciones MVC. En primer lugar, las refactorizaciones son más difíciles, muchos desarrolladores utilizan instancias IQueryable a partir de las vistas y después de luchar con el hecho de que al resolver IQueryable la conexión ya estaba eliminada. Problemas de rendimiento porque a menudo se consulta toda la base de datos para un conjunto dado de resultados, etc.

Prefiero exponer Iumerable de mis repositorios y créanme, me ahorra muchos problemas.

Answer 2

Está bien usar POCOs, pero tenga en cuenta que EntityObject no requiere una ObjectContext.

Sí, los tipos complejos son objetos de valor y sí, puede generarlos en el diseñador. Seleccione varias propiedades de una entidad, haga clic con el botón derecho y elija refactorizar en tipo complejo.

Recomiendo poner métodos comerciales en sus propios tipos, no en entidades. Los tipos "anémicos" pueden ser un problema si debe mantenerlos, pero cuando están codificados no son un problema de mantenimiento. Hacer que la lógica comercial se separe de los tipos de entidad permite que las reglas de su negocio y su modelo de datos evolucionen de manera independiente. Sí, debe usar clases parciales si debe mezclar estas preocupaciones, pero no creo que separar su modelo y sus reglas sea algo malo.

creo que los repositorios deben exponer IQueryable, pero se puede hacer un buen caso de que los servicios de dominio no debería. La gente a menudo intenta construir sus repositorios en servicios de dominio, pero recuerda que el repositorio existe solo para abstraer la persistencia. Preocupaciones como la seguridad deben estar en los servicios de dominio, y puede argumentar que tener IQueryable le da demasiada potencia al consumidor.

Answer 3

Creo que está bien exponer IQueryable fuera del repositorio, solo porque no hacerlo podría ser innecesariamente restrictivo. Si solo expone los datos a través de métodos como GetPeopleByBirthday y GetPeopleByLastName, ¿qué sucede cuando alguien va a buscar a una persona con el apellido y? ¿Atraes a todas las personas con el apellido "Smith" y haces una búsqueda lineal del cumpleaños que deseas, o creas un nuevo método GetPeopleByBirthdayAndLastName? ¿Qué hay del pobre tipo desventurado que tiene que implementar un formulario QBE?

Cuando la única manera de hacer consultas ad hoc contra el dominio era generar SQL, la única forma de mantenerse a salvo era ofrecer solo métodos específicos para recuperar y cambiar datos. Ahora que tenemos LINQ, sin embargo, no hay razón para mantener las esposas. Cualquiera puede enviar una consulta y puede ejecutarla de manera segura y sin preocupaciones.

Por supuesto, podría estar preocupado de que un usuario pueda ver los datos de otra persona, pero eso es fácil de mitigar porque puede restringir los datos que proporciona. Por ejemplo:

public IQueryable<Content> Content 
{ 
    get { return Content.Where(c => c.UserId == this.UserId); } 
} 

Esto se asegurará de que las únicas filas Content que el usuario puede obtener son los que tienen su UserId.

Si su preocupación es la carga en la base de datos, podría hacer cosas como examinar expresiones de consulta para escaneos de tabla (accediendo a tablas sin Where cláusulas o sin columnas indexadas en la cláusula Where). Por supuesto, eso no es trivial, y yo no lo recomendaría.