Patrón de repositorio vs servicio en DAL: EF y Dapper

asp.net-mvc dapper design-patterns entity-framework

Pregunta

Estoy trabajando en un proyecto y necesito diseñar el DAL. Utilizaré Entity Framework para la mayoría del proyecto y Dapper para algunas áreas sensibles al rendimiento.

Estaba pensando en usar el patrón Repositorio, pero EF ya implementa este patrón en algún sentido. Pero ese no es el caso con Dapper. Entonces me pregunto si es válido mezclar los patrones de Repository y Service en mi DAL. ¿O sería esto cruzar a la capa de lógica de negocios?

Una estructura de muestra que estaba pensando construir:

MyProjectName.Main
    Views/
    Controllers/
    Infrastructure/
    ...
MyProjectName.DAL
    DataService.EF/
        fileName.cs
        ...
    DataService.Dapper/
        fileName.cs
        ...

Respuesta aceptada

EF o cualquier otro ORM no implementa el Repositorio. El Repositorio está destinado a desacoplar el Dominio de la Persistencia. El dominio funciona con objetos de dominio, EF / Nhibernate / Dapper, etc. trabajan con entidades de persistencia que representan una vista de OOP de la base de datos relacional .

¿Ver la diferencia? Uno necesita objetos de negocios, el otro se ocupa de las estructuras de datos . Son similares pero no son lo mismo. Casos de concepto, comportamiento y uso de modelos de dominio, a Persistence le importa almacenar datos para que se recuperen rápidamente. Diferentes responsabilidades. El Repositorio actúa como mediador entre ellos, "convirtiendo" objetos de Dominio en estructuras de persistencia y viceversa.

Siempre, el ORM es un detalle de implementación del Repositorio. Para las aplicaciones CRUD, en las que realmente no tiene un Dominio, está tratando directamente con el DB, es decir, el (micro) ORM. En ese caso, Repo solo tiene sentido como fachada para dar un significado comercial al acceso a los datos ( GetOrders es mucho más fácil de entender que un SQL completo de Linq o 5 líneas une 3 tablas).

La interfaz del Repositorio se define donde se necesita, pero se implementa en Persistencia (DAL). Lo mismo con Servicios, se pueden definir (como una interfaz) en el Dominio, mientras que su implementación puede ser en DAL. Mientras que la implementación del repositorio casi siempre forma parte de DAL, solo algunos servicios residen en DAL, por la simple razón de que es más fácil para ellos hacer su trabajo de esa manera. Otros servicios pueden usar repositorios directamente (inyectados generalmente a través del constructor) y no tocan el DAL.

Sea cual sea el patrón que use, intente comprender su propósito real y siempre piense en el desacoplamiento.


Respuesta popular

Vea una implementación híbrida de EF + Dapper que Bradley Braithwaite ha creado.

Repo de GitHub: https://github.com/bbraithwaite/HybridOrm

Publicación de blog adjunta: ORM: no reinventar la rueda

En términos de estructurar las capas del proyecto para evitar el "sangrado", así es como lo hizo.

Diseño del proyecto

De la publicación del blog: Crear repositorio de datos usando Dapper



Licencia bajo: CC-BY-SA with attribution
No afiliado con Stack Overflow
Licencia bajo: CC-BY-SA with attribution
No afiliado con Stack Overflow