.net - tutorial - Desde el punto de vista organizativo, ¿dónde debería colocar consultas comunes cuando uso Entity Framework Code First?

entity framework ventajas y desventajas (3)

Estoy diseñando una nueva capa de datos usando EF 4.1 Code First, migrando desde una capa de datos homebrew más antigua.

He configurado dos conjuntos, uno para mi contexto y uno para todas las primeras clases del código POCO.

Tengo una lógica de negocios, por ejemplo, una consulta en una tabla (o algunas tablas) que se usa en varios lugares diferentes. ¿Dónde debería ponerlo?

No puede entrar en una clase POCO porque se une a un par de tablas y necesita un contexto. Podría ir en el contexto, pero ese contexto se inflaría con cientos de consultas desorganizadas. ¿Existe un patrón o arreglo común para toda la lógica comercial?

Parece que el patrón de repositorio es la solución para todo ... ¡El repositorio no es una bala de plata!

Estoy usando el patrón de repositorio con EF todos los días porque cuando comencé mi proyecto actual hace varios meses parecía la solución recomendada. Mis conclusiones:

El repositorio hace que la interacción con EF sea mucho más difícil. Simplemente examine las preguntas relacionadas con las etiquetas EF y verá qué complejidades deben manejarse directamente en el contexto, changetracker, etc.
El repositorio genérico es algo que funciona para las operaciones CRUD pero no para los escenarios DDD reales. Una vez que su repositorio funciona con raíces agregadas (DDD) falla el enfoque genérico.
Las pruebas unitarias no funcionan en absoluto porque la idea general de que se burlará del repositorio y probará su capa superior sin dependencias con EF y la base de datos falla una vez que expone IQueryable . Linq-to-entities es solo un subconjunto de Linq-to-objects y el simulacro no maneja la integridad referencial tantas veces que vi pruebas de unidades verdes y excepciones de tiempo de ejecución. El enfoque de prueba correcto con EF son las pruebas de integración. El repositorio de simulación solo sirve para probar la lógica comercial real que no está relacionada con el acceso a los datos. Si no tiene una prueba de integración para su método de negocio accediendo o persistiendo datos, no la ha probado.
Exponer métodos especializados como GetByXXX es solo un paso atrás. La mayoría de estos métodos se usan solo una vez. Finalizará con el código similar a los repositorios utilizados para envolver llamadas a procedimientos almacenados. A muchos desarrolladores les gusta ORM solo porque pueden evitar una arquitectura tan rígida.

EF ya ofrece un patrón de repositorio: DbSet y ObjectSet son repositorios y DbContext y ObjectContext son unidades de trabajo. Entonces, en mi opinión, el patrón de repositorio se usa en exceso. Puede ser útil en proyectos grandes en los que se necesita una estratificación estricta o en caso de colocar una lógica adicional a sus métodos. Usar el repositorio solo porque quiere ajustar el acceso a EF es a menudo un código sin valor y solo una capa adicional de complejidad.

De la misma manera, puede crear métodos reutilizables que definan sus consultas.

Si usa EF directamente en métodos comerciales (Servicios de capa de dominio y Servicios de capa de aplicación), entonces no está aislando la Capa de modelo de dominio de las tecnologías de infraestructura (EF en este caso). Ese es uno de los principios de DDD. probablemente deberías tener un Repositorio por Agregado.

Para obtener más información sobre DDD, ver:

El libro de Eric Evans: http://www.amazon.com/Domain-Driven-Design-Tackling-Complexity-Software/dp/0321125215

Microsoft: http://msdn.microsoft.com/es-es/architecture/en

Yo usaría el patrón de repositorio. Aquí hay un ejemplo que utiliza primero el código EF y MVC Entity Framework 4 CTP 4 / CTP 5 Modelo de repositorio genérico y unidad comprobable

Aquí hay algunas buenas lecturas sobre el patrón:

También puede ser una buena idea buscar en el Diseño Dirigido por Dominio (DDD) ya que está comenzando con un Modelo de Dominio.

Algunas buenas lecturas sobre DDD: