Zwiebel Architektur, die Einheit der Arbeit und ein generic Repository pattern

Kann ich sagen, dass dieser code ist gut genug für die erste Zeit versucht, aber es hat einige Plätze zu verbessern.

Let ' s gehen durch einige von Ihnen.

1. Dependency injection (DI) und die Nutzung des IoC.

Verwenden Sie die einfachste version Service-Locator-Muster - container Instanz selbst.

Ich schlage vor, Sie verwenden 'constructor injection'. Weitere Informationen finden Sie hier (ASP.NET MVC 4 Dependency Injection).

public class CustomerController : Controller
{
    private readonly IUnitOfWork unitOfWork;
    private readonly ICustomerRepository customerRepository;

    public CustomerController(
        IUnitOfWork unitOfWork, 
        ICustomerRepository customerRepository)
    {
        this.unitOfWork = unitOfWork;
        this.customerRepository = customerRepository;
    }

    public ActionResult List()
    {
        return View(customerRepository.Query());
    }

    [HttpPost]
    public ActionResult Create(Customer customer)
    {
        customerRepository.Add(customer);
        unitOfWork.SaveChanges();
        return RedirectToAction("List");
    }
}

2. Unit of Work (UoW) Umfang.

Kann ich nicht finden lebensstil IUnitOfWork und ICustomerRepository. Ich bin nicht vertraut mit Unity aber msdn sagt, dass TransientLifetimeManager wird standardmäßig verwendet. Es bedeutet, dass Sie erhalten eine neue Instanz jedes mal, wenn Sie das Problem beheben geben.

Also, folgender test fehl:

[Test]
public void MyTest()
{
    var target = new UnityContainer();
    target.RegisterType<IUnitOfWork, EntityFrameworkUnitOfWork>();
    target.RegisterType<ICustomerRepository, CustomerRepository>();

    //act
    var unitOfWork1 = target.Resolve<IUnitOfWork>();
    var unitOfWork2 = target.Resolve<IUnitOfWork>();

    //assert
    //This Assert fails!
    unitOfWork1.Should().Be(unitOfWork2);
} 

Und ich erwarte, dass die Instanz von UnitOfWork im controller unterscheidet sich von der Instanz des UnitOfWork im repository. Manchmal kann es sein, führte zu Fehlern. Aber es wird nicht hervorgehoben, in der ASP.NET MVC 4 Dependency Injection als ein Problem für die Einheit.

In Schloss Windsor PerWebRequest lebensstil wird verwendet, um teilen sich die gleiche Instanz des Typs innerhalb der einzelnen http-Anforderung.

Es ist gemeinsame Ansatz, wenn UnitOfWork ist ein PerWebRequest Komponente. Benutzerdefinierte ActionFilter können genutzt werden, um Sie aufrufen Commit() beim Aufruf von OnActionExecuted() Methode.

Ich würde auch umbenennen, die SaveChanges() - Methode, und rufen Sie es einfach Commit wie es genannt wird, in der Beispiel und in der PoEAA.

public interface IUnitOfWork : IDisposable
{
    void Commit();
}

3.1. Abhängigkeiten von repositories.

Wenn Ihr repositories gehen, um die 'leere' ist es nicht erforderlich, um spezifische Schnittstellen für Sie. Es ist möglich, Sie zu lösen IRepository<Customer> und habe den folgenden code in Ihr controller

public CustomerController(
    IUnitOfWork unitOfWork, 
    IRepository<Customer> customerRepository)
{
    this.unitOfWork = unitOfWork;
    this.customerRepository = customerRepository;
}

Es ist ein test, der prüft es.

[Test]
public void MyTest()
{
    var target = new UnityContainer();
    target.RegisterType<IRepository<Customer>, CustomerRepository>();

    //act
    var repository = target.Resolve<IRepository<Customer>>();

    //assert
    repository.Should().NotBeNull();
    repository.Should().BeOfType<CustomerRepository>();
}

Aber wenn Sie möchte haben Repositorys, die 'Ebene der Abstraktion über die mapping-Schicht, wo die Abfrage Baugesetzbuch konzentriert ist.' (PoEAA, Repository)

Einem Repository vermittelt zwischen dem Domänen-und Daten-mapping-Schichten,
benimmt sich wie ein in-memory-Domäne-Objekt-Sammlung. Client-Objekte
konstruieren Abfrage Spezifikationen deklarativ und legt Sie auf die
Repository für Zufriedenheit.

3.2. Vererbung auf EntityFrameworkRepository.

In diesem Fall würde ich erstellen Sie eine einfache IRepository

public interface IRepository
{
    void Add(object item);

    void Remove(object item);

    IQueryable<T> Query<T>() where T : class;
}

und deren Umsetzung, der weiß, wie die Arbeit mit Entity Framework-Infrastruktur und kann leicht durch ein anderes ersetzt (z.B. AzureTableStorageRepository).

public class EntityFrameworkRepository : IRepository
{
    public readonly EntityFrameworkUnitOfWork unitOfWork;

    public EntityFrameworkRepository(IUnitOfWork unitOfWork)
    {
        var entityFrameworkUnitOfWork = unitOfWork as EntityFrameworkUnitOfWork;

        if (entityFrameworkUnitOfWork == null)
        {
            throw new ArgumentOutOfRangeException("Must be of type EntityFrameworkUnitOfWork");
        }

        this.unitOfWork = entityFrameworkUnitOfWork;
    }

    public void Add(object item)
    {
        unitOfWork.GetDbSet(item.GetType()).Add(item);
    }

    public void Remove(object item)
    {
        unitOfWork.GetDbSet(item.GetType()).Remove(item);
    }

    public IQueryable<T> Query<T>() where T : class
    {
        return unitOfWork.GetDbSet<T>();
    }
}

public interface IUnitOfWork : IDisposable
{
    void Commit();
}

public class EntityFrameworkUnitOfWork : IUnitOfWork
{
    private readonly DbContext context;

    public EntityFrameworkUnitOfWork()
    {
        this.context = new CustomerContext();
    }

    internal DbSet<T> GetDbSet<T>()
        where T : class
    {
        return context.Set<T>();
    }

    internal DbSet GetDbSet(Type type)
    {
        return context.Set(type);
    }

    public void Commit()
    {
        context.SaveChanges();
    }

    public void Dispose()
    {
        context.Dispose();
    }
}

Und jetzt CustomerRepository kann ein proxy und beziehen sich auf Sie.

public interface IRepository<T> where T : class
{
    void Add(T item);

    void Remove(T item);
}

public abstract class RepositoryBase<T> : IRepository<T> where T : class
{
    protected readonly IRepository Repository;

    protected RepositoryBase(IRepository repository)
    {
        Repository = repository;
    }

    public void Add(T item)
    {
        Repository.Add(item);
    }

    public void Remove(T item)
    {
        Repository.Remove(item);
    }
}

public interface ICustomerRepository : IRepository<Customer>
{
    IList<Customer> All();

    IList<Customer> FindByCriteria(Func<Customer, bool> criteria);
}

public class CustomerRepository : RepositoryBase<Customer>, ICustomerRepository
{
    public CustomerRepository(IRepository repository)
        : base(repository)
    { }

    public IList<Customer> All()
    {
        return Repository.Query<Customer>().ToList();
    }

    public IList<Customer> FindByCriteria(Func<Customer, bool> criteria)
    {
        return Repository.Query<Customer>().Where(criteria).ToList();
    }
}

Ich sehe paar ernsthafte Probleme im code.

Das 1. problem ist relashionship zwischen Repositorys und UoW.

    var unitOfWork = container.Resolve<IUnitOfWork>();
    var customerRepository = container.Resolve<ICustomerRepository>();

Hier ist die implizite Abhängigkeit. Repository wird nicht funktionieren, selbst ohne UoW! Nicht alle repositories angeschlossen werden muss, mit UoW. Zum Beispiel was über gespeicherte Prozeduren? Sie haben die gespeicherte Prozedur, und Sie verstecken es hinter repository. Gespeicherte Prozedur-Aufruf verwendet separate Transaktion!!! Zumindest nicht in allen Fällen. Also wenn ich das beheben das nur repository und hinzufügen, dann wird es nicht funktionieren. Außerdem ist dieser code wird nicht funktionieren, wenn ich Vorübergehende Lebens-Lizenz, weil repository haben einen UoW-Instanz. So haben wir engen implizite Kopplung.

Dem 2. problem, das Sie erstellen, die enge Kopplung zwischen den DI-container Motor und verwenden Sie es als service locator! Service locator ist kein guter Ansatz zu implementieren IoC und aggregation. In einigen Fällen ist es anti-pattern. DI-container sollte verwendet werden,