¿Ya se necesitan repositorios en ASP.net 5 y EF7?

9

Publiqué una pregunta en github para el equipo EF. Recibí una respuesta que decía que sería mejor hacer esta pregunta aquí, así que la copiaré y pegaré aquí como un enlace para que otros puedan ver las pocas respuestas en GitHub.

Pregunta: Estaba investigando y alguien señaló que la línea 24 de la clase DBContext dice

DbContext es una combinación de los patrones de Unidad de trabajo y Repositorio.

¿Significa esto que ya no necesitamos abstraer EF a un repositorio y luego usar una interfaz para inyectarlo en los controladores?

Publicación original en Github: https://github.com/aspnet/EntityFramework/issues/4899

La razón por la que pregunto esto es que parece que me encuentro en un lugar donde estoy agregando muchos métodos al repositorio como GetById, GetByName, GetWithIncludesABC, GetWithIncludes123, etc. y parece estar ensuciando el repositorio en mi mente

asp.net-mvc  entity-framework  repository 
— Loren.Dorez
fuente
1
¿Qué opinas de la respuesta que dio rowanmiller? Suena perfectamente razonable para mí.
— Robert Harvey
@RobertHarvey Sí, fue una buena respuesta, pero quiero ver cómo se sienten los demás sobre el tema antes de tomar una decisión de repositorio o no
— Loren.Dorez
vea también lostechies.com/jimmybogard/2009/09/11/wither-the-repository donde Bogard argumenta de manera similar.
— mcknz
Mi opinión sobre por qué EF (y otros ORM) no son repositorios .
— Eric King
Un repositorio no tendría un método como GetWithIncludesABC. El patrón de repositorio es una abstracción de, básicamente, una tabla de base de datos como una colección. Por lo general, es posible consultar la colección (por ejemplo, mediante LINQ), y el repositorio luego convierte la consulta en SQL. De lo que estás hablando suena más como un Data Gateway.
— Sr. Cochese

Respuestas:

12

Si está agregando métodos a un repositorio como 

GetById 
GetByName 
GetWithIncludesABC
GetWithIncludes123

Entonces es mejor pasar a una capa de servicio y dejar que la capa de servicio use EF directamente. EF ya tiene una funcionalidad similar a los métodos anteriores que simplemente está duplicando sin cesar.

Una capa de servicio expone los métodos del dominio comercial y utiliza CRUD para implementarlos. Por ejemplo, puede tener un método llamado TransferMoney(A, B), donde A y B son cuentas corrientes. Esto le permite hablar el idioma de su dominio comercial, mientras que la capa de servicio maneja el CRUD por usted.

La única razón convincente por la que puedo pensar en dónde podría desear tener una capa de repositorio separada es para que pueda burlarse de esa capa de repositorio o sustituir una fuente de datos diferente para fines de prueba.

— Robert Harvey
fuente
Sin embargo, puede burlarse de dbset ... msdn.microsoft.com/en-us/library/dn314429(v=vs.113).aspx
— S1r-Lanzelot
4

Robert Harvey dijo en su respuesta:

La única razón convincente por la que puedo pensar en dónde podría desear tener una capa de repositorio separada es para que pueda burlarse de esa capa de repositorio o sustituir una fuente de datos diferente para fines de prueba.

Esto es precisamente por qué el patrón de repositorio sigue siendo relevante. Tampoco estoy de acuerdo con la afirmación de los equipos de Entity Framework de que implementan el Patrón de repositorio. Entity Framework todavía está muy vinculado a una base de datos. Todo el propósito del Patrón de repositorio es desacoplar y abstraer el mecanismo exacto de persistencia utilizado en su aplicación, de modo que nada de la implementación del acceso a datos se filtre fuera de la capa de repositorio.

Si está utilizando la API de consulta EF fuera del "repositorio", como en un objeto de servicio de algún tipo, diría que está rompiendo el patrón.

Ahora, si no es un problema catastrófico para la base de datos, como la funcionalidad, filtrarse en su otro código, y puede garantizar que no necesitará mover algunas de sus operaciones CRUD a un servicio web en el futuro, entonces usar EF directamente sería OKAY.

Básicamente, Entity Framework toma el lugar del objeto Gateway en el Patrón de repositorio. No lo veo como un repositorio en sí.

— Greg Burghardt
fuente
¿Cómo difiere el repositorio de un aspecto de la capa de servicio? de lo que puedo encontrar si estoy devolviendo IQueryable, entonces soy esencialmente un Repositorio si estoy regresando IEnumerable, entonces estoy usando una capa de servicio. ¿Es esto correcto? ¿Son similares la capa de servicio y los patrones de repositorio?
— Loren.Dorez
@ Loren.Dorez: una capa de servicio tiene métodos específicos de dominio empresarial, como TransferFunds()y BuildWidget(). Un repositorio solo contiene métodos CRUD.
— Robert Harvey
Entonces, ¿tanto una capa de servicio como un repositorio accederían directamente al DBContext? ¿Entonces pondría el CRUD en los métodos Repo y Get y otros métodos en la capa de servicio? ¿Estoy entendiendo esto correctamente?
— Loren.Dorez
La capa de servicio puede acceder al repositorio, si tiene uno, en lugar de EF directamente.
— Robert Harvey
@RobertHarvey ¿Puedes mostrarme un ejemplo usando el método Get Methds de arriba? Como ahora estoy un poco confundido lo siento.
— Loren.Dorez
Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.