Si Entity Framework / DbContext es el DAL / Repositorio, ¿dónde encaja dentro de la architecture de 3 niveles?

He estado leyendo artículos sobre StackOverflow y otros sitios durante todo el día sobre las mejores prácticas de architecture y hay tantas ideas y opiniones conflictivas.

Finalmente me decidí por un enfoque, pero me está costando mucho decidir dónde colocar los objetos EF (DbContext, Fluent APIs, Sembrar datos, etc.). Esto es lo que tengo actualmente:

ASP.NET MVC Project : El proyecto web real. Contiene las vistas estándar, los controladores y los modelos de vista (dentro de una carpeta de modelos ).

Proyecto de modelo de dominio : contiene todas las clases de POCO que definen los objetos de la base de datos (dominio). Actualmente, no menciona ni hace referencia a ningún objeto EF.

Proyecto de la capa de servicio : contiene objetos de servicio para cada tipo de objeto de dominio (p. Ej., IProductService, IOrderService, etc.). Cada servicio hace referencia a objetos EF como DbSets y maneja las reglas de negocios, por ejemplo, agregar un producto, obtener un producto, agregar un producto a un pedido, etc.

Entonces, la pregunta es, en esta configuración, ¿a dónde van las clases EF? Inicialmente pensé en la capa de servicio, pero eso no parece tener sentido. Entonces pensé en ponerlos en la Capa de Modelo de Dominio, pero luego vincula los Modelos de Dominio a EF, que es esencialmente un DAL / Repositorio. Finalmente, pensé en crear un Proyecto DAL separado solo para EF, pero parece un gran desperdicio considerando que probablemente tendrá 3-4 archivos (DbContext y algunos otros archivos pequeños).

¿Alguien puede proporcionar alguna orientación?

No hay necesidad de Modelo de Dominio ya que será redundante. Las clases EF directamente pueden actuar como Modelo de Dominio y se convierten en Modelos de Vista mientras se envían a Vista. EF se puede separar en diferentes bibliotecas de clases. La mayoría de ellos usan un patrón de repository junto con cualquier ORM en caso de que sea fácil si se los reemplaza. Pero he visto críticas sobre el uso del patrón de repository, mira esto .

Esto es lo que hago:

Datos:

  • Tiene una clase heredada de DbContext.
    • Tiene todos los conjuntos de db.
    • Anula OnModelCreating.
    • Mapeo de claves primarias y relaciones.

Entidades:

  • Tiene todas las clases de POCO.
    • Cada propiedad está decorada con anotaciones de datos necesarios.

Servicios:

  • Cada servicio tiene métodos comunes (GetList (), Find (), Create (), etc.).

Negocio:

  • Llamado desde los clientes, organice el uso de los servicios para realizar una tarea específica UserChangePassword (esto verificará si esto puede realizarse, luego realizará la tarea o devolverá estados de error / no autorizados entre muchos otros para hacer que el cliente muestre la información correcta sobre la tarea. En mi caso es donde me registro.

Clientes (Escritorio / Web / Wpf / etc).

No estoy diciendo que este sea el mejor enfoque, solo estoy compartiendo lo que me ha funcionado.