Patrón genérico de repositorio con UnitOfWork Patrón

Question

Estoy tratando de implementar un patrón genérico de repositorio. Encontré este sitio que creo que está bien explicado. http://www.tugberkugurlu.com/archive/generic-repository-pattern-entity-framework-asp-net-mvc-and-unit-testing-triangle

Mi propósito es salvar a los desarrolladores con el tiempo y las teclas y sé que esto me ayudará.

Así que tengo 2 preguntas:
1. ¿Es este un buen enfoque o no, tendré algunos problemas en el futuro?
2. ¿Cómo puedo combinarlo con el patrón Unitofwork ?, no puedo crear una instancia de la clase abstracta por supuesto, por lo que el siguiente código no es válido.

public class UnitOfWork : IDisposable 
    { 
     #region Private fields 
     private readonly MyCompanyContext _context = new MyCompanyContext(); 
     private GenericRepository<MyCompanyContext, Task> _taskRepository; 

     public GenericRepository<MyCompanyContext, Task> TaskRepository 
     { 
      get 
      { 
       return _taskRepository ?? 
         (_taskRepository = new GenericRepository<MyCompanyContext, Task>()); 
      } 
     } 




namespace MyCompany.DAL.Repository 
{ 
    public interface IGenericRepository<T> where T : class 
    { 
     IQueryable<T> GetAll(); 
     IQueryable<T> FindBy(Expression<Func<T, bool>> predicate); 
     void Add(T entity); 
     void Delete(T entity); 
     void Edit(T entity); 
     void Save(); 
    } 

    public abstract class GenericRepository<C, T> : 
    IGenericRepository<T> 
     where T : class 
     where C : DbContext, new() 
    { 

     private C _entities = new C(); 
     public C Context 
     { 

      get { return _entities; } 
      set { _entities = value; } 
     } 

     public virtual IQueryable<T> GetAll() 
     { 

      IQueryable<T> query = _entities.Set<T>(); 
      return query; 
     } 

     public IQueryable<T> FindBy(System.Linq.Expressions.Expression<Func<T, bool>> predicate) 
     { 
      IQueryable<T> query = _entities.Set<T>().Where(predicate); 
      return query; 
     } 

     public virtual void Add(T entity) 
     { 
      _entities.Set<T>().Add(entity); 
     } 

     public virtual void Delete(T entity) 
     { 
      _entities.Set<T>().Remove(entity); 
     } 

     public virtual void Edit(T entity) 
     { 
      _entities.Entry(entity).State = System.Data.EntityState.Modified; 
     } 

     public virtual void Save() 
     { 
      _entities.SaveChanges(); 
     } 
    } 
} 

Answer 1

Hay varias opiniones con respecto a los repositorios, pero después de probar varias implementaciones del repositorio en la producción de dos años a mí mismo, estoy de acuerdo con Ayende's opinión, ese repositorio, especialmente genérico, es decir la capa de abstracción redundante.

Me gustó mucho este curso: http://www.pluralsight-training.net/microsoft/Courses/TableOfContents/linq-architecture

caminaba a través de la mayoría de las soluciones posibles y explicó bienes y males.

Lo que estamos usando ahora es una abstracción muy delgada sobre el contexto de datos, solo para superar los problemas de prueba de Linq2Sql, que son irrelevantes en la mayoría de los casos cuando se usa EF.

Answer 2

Con mucho esfuerzo puede que funcione, pero me pregunto si el esfuerzo realmente lo vale. He visto implementaciones como esta antes, y realmente tienen dificultades cuando intentan administrar relaciones de muchos a muchos (piense en cómo lo manejaría en su escenario). ¿Está utilizando Entity Framework, un ORM correcto? ORM como Entity Framework y nHibernate son diseñados para abstraer la implementación de la base de datos del código de la aplicación, entonces, ¿cuál es el propósito de agregar otra abstracción arriba para gestionar entidades a un nivel tan granular? Si se trata de pruebas, puede utilizar un marco de burla para burlarse del contexto, eliminando así la necesidad de una base de datos real durante las pruebas. Sin embargo, si por motivos arquitectónicos o de seguridad está tratando de eliminar las interacciones con un contexto db del código de su aplicación, lo recomendaría para el pragmatismo utilizando una implementación del patrón de comando en la parte superior del marco de la entidad. He necesitado hacer esto en una aplicación empresarial (bancaria) de mayor escala donde por razones de seguridad (correcta o incorrectamente) no se nos permitió tener una conexión db en nuestro código de aplicación.