Patrón del repositorio Explicación paso a paso [cerrado]

276

¿Puede alguien explicarme el Patrón de repositorio en .NET, paso a paso, dando un ejemplo o demostración muy simple?

Sé que esta es una pregunta muy común, pero hasta ahora no he encontrado una respuesta satisfactoria.

c# asp.net design-patterns repository

— Sa Patil
fuente

msdn.microsoft.com/en-us/library/ff649690.aspx y codeproject.com/Tips/309753/…

— Maarten

Hay un buen artículo aquí: deviq.com/repository-pattern

— ssmith

Respuestas:

199

Como resumen, describiría el impacto más amplio del patrón de repositorio. Permite que todo su código use objetos sin tener que saber cómo persisten los objetos. Todo el conocimiento de la persistencia, incluida la asignación de tablas a objetos, está contenido de forma segura en el repositorio.

Muy a menudo, encontrará consultas SQL dispersas en la base de código y cuando viene a agregar una columna a una tabla, debe buscar archivos de código para intentar encontrar los usos de una tabla. El impacto del cambio es de gran alcance.

Con el patrón de repositorio, solo necesitaría cambiar un objeto y un repositorio. El impacto es muy pequeño.

Quizás sería útil pensar por qué usaría el patrón de repositorio. Aquí hay algunas razones:

Tiene un solo lugar para realizar cambios en su acceso a datos
Tiene un solo lugar responsable de un conjunto de tablas (generalmente)
Es fácil reemplazar un repositorio con una implementación falsa para las pruebas, por lo que no necesita tener una base de datos disponible para sus pruebas unitarias

También hay otros beneficios, por ejemplo, si estaba usando MySQL y quería cambiar a SQL Server, ¡pero en realidad nunca lo había visto en la práctica!

— Fenton
fuente

RE cambiando de dbms a a b, dejaré constancia de que no solo he visto esto, sino que lo he hecho en el código de producción. Anteriormente estábamos usando Oracle, tuvimos que cambiar de proveedor de alojamiento, nos instalamos en Azure (antes de que admitieran Oracle), por lo que tuvimos que convertir a SQL Azure. Desafortunadamente, no habíamos separado toda la lógica de acceso a datos en ese punto, pero ciertamente lo hicimos como lo hicimos en esa migración (y en el futuro, podría agregar).

— Joe

Sé que este comentario es antiguo y cerrado como fuera de tema, pero lo he visto en varias compañías. Por lo general, es parte de un proceso para avanzar o alejarse de un ORM. El repositorio hace que sea más fácil cambiarlo, especialmente si los carga desde un patrón de fábrica abstracto o usa un contenedor de IoC.

— Derek Van Cuyk

En realidad, Repository utiliza DAO para sus operaciones relacionadas con la fuente de datos ...

— Yousha Aleayoub

@YoushaAleayoub que un buen punto planteas. Normalmente encontrará Objetos de acceso a datos cuando las personas intentan "separar la base de datos" y los repositorios cuando las personas intentan "hacer que una sola cosa sea responsable de la consulta". En casi todos los casos, los encontrará juntos. La parte DAO es el IConnection, ICommand, etc parte que oculta el tipo de base de datos. El repositorio suele estar más centrado en el dominio.

— Fenton

181

Este es un buen ejemplo: el ejemplo de patrón de repositorio en C #

Básicamente, el repositorio oculta los detalles de cómo exactamente los datos se obtienen / persisten de / a la base de datos. Debajo de las sábanas:

para leer, crea la consulta que satisface los criterios proporcionados y devuelve el conjunto de resultados
para escribir, emite los comandos necesarios para hacer que el motor de persistencia subyacente (por ejemplo, una base de datos SQL) guarde los datos

— dos flores
fuente

Este ejemplo es la mejor explicación, simplemente mejor que la documentación de MSDN.

— Teoman shipahi

He encontrado esta muy bueno. También proporciona una explicación decente sobre la Unidad de trabajo, que parece ser una forma más genérica del Patrón de datos sobre el Patrón de repositorio

— Celdor

El ejemplo vinculado es una falla de patrón de repositorio. No ofrece ninguna ventaja en comparación con el uso de las interfaces proporcionadas por Entity Framework ( IDbContext) o en nhibernate ( ISession) directamente. Un repositorio implementado correctamente extrae TODA la información específica de persistencia (como cómo funciona el proveedor actual de Linq To Sql). es decir, nunca exponer IQueryable.

— jgauffin

@jgauffin IQueryableno es información específica de persistencia. El respaldo de IQueryable podría ser tan simple como una matriz codificada, o podría ser de un archivo XML, servicio web, base de datos, archivo plano, etc. No recomendaría un repositorio que no exponga IQueryable como siempre conduce a un acceso lento a los datos en todos los casos, donde exponer IQueryable permitirá que algunas instancias realicen mejoras de rendimiento cuando corresponda si el almacén de persistencia tiene esa capacidad. Además, ocultar DbContext le permite cambiar a un ORM diferente si es necesario (¡o no ORM!)

— Robert McKee

Se filtra información persistente información específica. Intente utilizar la carga ansiosa / lenta o crear una INcláusula sql sin saber cómo lo hace el proveedor específico de LinqToSql.

— jgauffin