¿Patrones para usar EntityFramework?

Question

¿Cuáles son los patrones alternativos de uso para Entity Framework?

Algunos que conozco son:

1. " Llano " EntityFramework - también conocido como Unidad de trabajo

   using (Data.Model c = new Data.Model())
   {
       var z = c.Users.Where(x=>x.Name=='John');
   }
   
   

2. Patrón de repositorio

   //Model implements IRepository
   User user = Model.Instance.Get<User>(u => u.Name == "John");
   

3. ¿Qué más?
4. ?

Answer 1

Un buen libro para mirar es " Patrones de arquitectura de aplicaciones empresariales " .

Allí pasa por algunos patrones para recuperar / mapear datos como DTO, Unidad de trabajo, patrón de repositorio, etc. Quizás algo podría ser útil junto con el Entity Framework. Tendría que echarle un vistazo.

Answer 2

Respondo su pregunta basándose en el supuesto de que está utilizando Entity Framework directamente en su UI / controlador / Servicios.

Se ha demostrado que el uso de cualquier ORM, incluido EF, directamente en su UI / Controladores / Servicios causará muchos problemas en el futuro. Además de eso, hace que sea muy difícil, si no imposible, realizar una prueba unitaria de su aplicación.

El segundo enfoque, es decir, "Modelo implementa el repositorio" también es incorrecto en mi opinión, porque el Modelo y los Depósitos tienen diferentes responsabilidades y se basan en "Responsabilidad única" Como parte de los principios SOLIDOS, no debe fusionar los dos conceptos. Incluso si desea utilizar el patrón de Objetos activos en su modelo, que no recomiendo, debe desacoplar su modelo del ORM que usa.

La solución mejor y más recomendada es tener una interfaz como IRepository o IRepository con los miembros más básicos como sugiere el patrón. algo como:

Interface IRepository<T> where T:class
{
    void Insert(T entity);
    void Update(T entity);
    void Delete(T entity);

    // if you don't want to return IQueryable
    T FindById(object id);
    IEnumerable FindXXXXX(params)

    // if you prefer to return an IQueryable
    IQueryable<T> Find(Expression<Func<T, bool>> predeicate);
}

Tenga en cuenta que algunos repositorios creyentes no deberían devolver IQueryable. Además, puede considerar el uso de ISpecification en lugar de expresiones y lambda.

necesitaría implementar la interfaz IRepositoy para la mayoría de sus entidades. Con este enfoque también puede burlarse de sus repositorios al escribir pruebas unitarias. En producción, necesitaría usar un proveedor de Ioc como Unity, Ninject, Linfu, Catsle, etc. También puede beneficiarse de la implementación del localizador de servicios comunes de Microsoft para evitar el acoplamiento a un marco de IoC específico.

En los viejos tiempos, solía tener una interfaz de acceso a datos que se implementó para un dominio comercial específico o un servicio. Uno de los problemas con este enfoque es que terminaría con un código duplicado en diferentes servicios de acceso a datos si realiza un seguimiento de su código fuente y eventualmente lo hará.

Answer 3

Utilizamos un código similar al que tiene en su unidad de trabajo de ejemplo.

Lo que hacemos además es asignar objetos a objetos de transferencia de datos.

Answer 4

Hay muchos artículos sobre el tema, pero la lista se reducirá sustancialmente si desea uno bueno. Este artículo de MSDN Magazine es bastante bueno, aunque se ocupa específicamente de las aplicaciones de n niveles. Pero como no dices lo que estás construyendo, tal vez te ayude.

Answer 5

LINQ 2 SQL puede ser una alternativa. Aquí hay un artículo Inyección de dependencia con Unity y Linq a SQL DataContexts

UNIDAD - http://unity.codeplex.com/