.net - pattern - Patrón de repositorio con marco de entidad

repository pattern c# entity framework core

Question

El patrón de repositorio se usa para abstraer de la base de datos particular y la tecnología de mapeo de relación de objeto (como EF) utilizada. Así que puedo reemplazar fácilmente (por ejemplo) mis asignaciones de Entity framework con Linq a SQL en el futuro si decido hacerlo.

Pero cuando uso EF tengo mis clases de entidad del modelo, es decir, se generan a partir de ese diagrama visual. Si uso estas clases de entidad generadas en mi repositorio y luego decido reemplazar EF por otra cosa, eliminaré el diagrama de entidad visual y eso significa también eliminar clases, ¿no?

El punto al que me dirijo es que mi repositorio dependerá del marco de Entity, que está en la capa de acceso a datos porque utilizará las clases generadas por EF.

¿Cómo elimino esta dependencia?

También tenga en cuenta que uso EF principalmente debido a su capacidad para generar todo a partir de ese diagrama visual: simplemente diseño el diagrama y le dejo generar una base de datos para mí con todas las claves externas, etc. Me gusta mucho y no quiero ni siquiera pensar en los comandos SQL.

Answer 1

Las clases de entidad creadas por el diseñador de EF están allí en su proyecto, dentro de su "Model.Designer.cs" . Puede copiar el código para que sus entidades permanezcan en su proyecto, incluso si elimina su modelo o las referencias de EF. Sin embargo, están estrechamente vinculados a EF, por lo que debe esforzarse por desacoplar EF de sus clases de entidad.

Hasta ahora, tenías plantillas T4 que podrían ayudarte con el desacoplamiento, pero aún requerirían algunos cambios en el T4 elegido:

• ADO.NET EntityObject Generator
• ADO.NET POCO Entity Generator
• Generador de entidades de seguimiento automático ADO.NET

EF4.1 trae una API simplificada, DbContext , que mejora su experiencia con EF cuando desea desacoplar las clases de entidad. Con EF4.1 obtienes 3 enfoques:

• Codificar primero
  • usted crea las clases y EF crea el DB como debería ser
  • las clases no desaparecerán cuando elimines las referencias a EF
  • no tendras ningun diseñador
• Base de datos primero
  • Si ya tiene una base de datos, se creará un modelo para usted en el diseñador.
  • puede crear sus clases de entidad con la nueva plantilla T4 DbContext Generator
• Modelo primero
  • Como ya lo haces ahora, creas tu modelo en el diseñador.
  • puede crear clases de entidad con DbContext Generator

Ahora, respondiendo a tu pregunta:

¿Cómo elimino esta dependencia?

1. Instalar EF4.1
2. Crea tu modelo (usando el enfoque Modelo-primero)
3. Genera tu base de datos desde tu modelo
4. Genere sus clases de entidad con DbContext Generator

Vea cómo puede hacer todo esto aquí: EF 4.1 Model & Database First Walkthrough .
Debería leer la serie en el Blog del equipo de ADO.NET Uso de DbContext en la característica EF CTP5 Parte 1: Introducción y modelo (EF4.1 se conocía anteriormente como Característica EF CTP5) .
Puede obtener más detalles en mi pregunta: el código EF POCO solo VS EF POCO con Entity Data Model .

Answer 2

Tener la capacidad de cambiar de una tecnología de persistencia a otra es bueno y todo, pero ¿realmente lo necesita?

En primer lugar, ¿qué es un repositorio? Según la definición de Fowler, proporciona un acceso similar a una colección en memoria a objetos de dominio. Pero cada herramienta ORM moderna ya lo hace, por lo que otro nivel de abstracción solo agrega un poco más de complejidad.

En segundo lugar, el cambio de una tecnología de persistencia a otra suele ser más complejo que simplemente proporcionar otra implementación de repositorio. Por ejemplo, ¿cómo piensa manejar las transacciones? Las transacciones generalmente dependen del contexto y se manejan fuera de los repositorios. Por supuesto, podría usar algún tipo de unidad de implementación de trabajo, pero luego tendría que implementar una nueva unidad de trabajo para cada tecnología de persistencia.

No quiero decir que no debas usar repositorios, solo dale otra idea.

Answer 3

Un repositorio siempre depende de la tecnología de acceso a datos. Es la razón por la que las personas están usando repositorios para envolver la dependencia de acceso a los datos en una capa separada. Si decides cambiar la tecnología de acceso a los datos (en este caso es como un 1% de probabilidad de que lo hagas), tendrás que crear nuevos repositorios implementando las mismas interfaces que los anteriores.

La introducción de repositoris añadirá una nueva capa de complejidad. Los repositorios tienen sus pros y sus contras. Presentarlos solo porque "puede cambiar el enfoque de acceso a los datos en el futuro" es una mala razón. No diseñe su aplicación porque algo puede suceder. Diseñe la aplicación de acuerdo con los requisitos reales actuales (una forma ágil) y refactorice su código si se necesita un cambio: esa es la única manera de ser competitivo en el mercado. Las características están vendiendo su SW, no su arquitectura abierta para cualquier tipo de cambio (está bien, hay excepciones, pero en tales casos, la arquitectura abierta es un requisito de nivel superior).

Cuando usas EF tienes varias opciones de cómo crear entidades:

• Usa la herramienta cutom para generar objetos de entidad. Este es el enfoque predeterminado que crea el archivo "código detrás" para EDMX. Es la única solución disponible en EFv1 (.NET 3.5 SP1).
• Use plantillas T4 para generar objetos de entidad, POCO, STE o cualquier tipo de entidad personalizada (puede modificar la lógica de generación). Esto se utiliza a menudo con EFv4.
• Escribe POCOs por ustedes mismos. Esto se puede usar con EFv4 y siempre se usa con el enfoque de código primero en EF 4.1.

Si espera que la tecnología de acceso a los datos pueda cambiar en el futuro, use el segundo o el tercer enfoque con POCO. En el caso de las plantillas T4, puede simplemente copiar los POCO generados o modificar un archivo de proyecto para no perderlos después de eliminar el archivo EDMX.

Si no está seguro de si el segundo o el tercer enfoque le conviene, verifique mis respuestas a estas preguntas:

• ADO.NET DbContext Generator vs. ADO.NET POCO Entity Generator
• Código EF POCO solo VS EF POCO con modelo de datos de entidad

Como de alguna manera estoy de acuerdo con la respuesta de @ Patko, también deberías consultar el blog de Ayende . Ha escrito varias publicaciones sobre el uso de repositorio y sobre aplicaciones de arquitectura. Él está escribiendo sobre NHibernate, pero se pueden tomar decisiones similares con EF. La única diferencia es que NHibernate ofrece una mejor abstracción, por lo que el código que usa directamente NHibernate se puede probar mejor.

Answer 4

Una de las nuevas características de Entity Framework versión 4 es el desarrollo "Code First". Esto le permitirá usar clases regulares de C # (POCO) con el marco de la entidad. Una vez que sus clases estén escritas de esta manera, podría escribir una implementación diferente del repositorio que persista en esas clases usando un mecanismo diferente.

ScottGu tiene una publicación en el blog que contiene más información.