Arbeitseinheit, Entity Framework DbContext Scope

Question

Ich habe in ein bisschen ein Problem mit EF laufen für dieses Problem für die beste Praxis suchen:

public void TestEntityFramework_UOWImplementation() 
{ 
    using (UnitOfWorkInventory uow = new UnitOfWorkInventory()) 
    { 
     IMaterialRepository repos = new MaterialRepository(uow); 

     Material mat = GetMaterial("Mikes Material", 1); 

     mat.CostPrice = 20; 

     repos.InsertOrUpdate(mat); 

     uow.Commit(); 
    } 
} 

private Material GetMaterial(string sku, int clientId) 
{ 
    IMaterialRepository repos = new MaterialRepository(new UnitOfWorkInventory(); 

    return repos.Find(sku, clientId); 

} 

Im TestEntityFramework_UOWImplementation() -Methode, seine feinen, i Rufen Sie einen Bereich für meine Arbeitseinheit an .. und erstellen Sie darin ein Repository.

Aber wenn ich willMaterials() wie unten .. Ich habe keinen Zugriff auf die Arbeitseinheit oder das Repository, es sei denn, ich übergebe es tatsächlich als Parameter! Das ist eindeutig nicht besonders nett.

Wie umgehen die Leute dieses Problem?

Vielen Dank im Voraus!

Neil

Answer 1

Wenn jemand nach einem Weg um dies suchte, habe ich etwas ein bisschen anders gemacht.

Ich habe ein Dependency Injection-Framework (StructureMap) verwendet, um alle DIs zu verarbeiten. Jedes Mal, wenn ich ein Repository instanziiere, ruft es den DBContext vom Service Locator von StructureMap ab. Ich mache auch den dbcontext-Bereich für die Dauer der Anfrage vom Webserver.

Der Vorteil hier ist, dass jedes Mal, wenn ich einen DBContext abrufe oder einspreche, er den gleichen Kontext für die Dauer der Anfrage abrufen wird, was bedeutet, dass ich ihn über mehrere Methoden und Klassen verwenden kann! Ich gebe den Interface-Typ als generischen Parameter an den Konstruktor, was bedeutet, dass ich den Repo als verschiedene Kontexte zeigen kann. Hilfreich bei Anwendungen mit vielen dbcontexts.

Repo Constructor ZB:

public class PurchaseOrderRepository<TDbContext> : GenericRepository<PurchaseOrder>, IPurchaseOrderRepository<TDbContext> where TDbContext : DbContext 
{ 

     public PurchaseOrderRepository() 
      : base((TDbContext)ObjectFactory.GetInstance<TDbContext>()) 
     { 
     } 
} 

Verbrauch:

//resolves the request scope InventoryContext... 
var pRepos = new PurchaseOrderRepository<IInventoryContext>(); 

und die Struktur Karte Abhängigkeit wie folgt aussieht:

For<IInventoryContext>().HttpContextScoped().Use<InventoryContext>(); 

Answer 2

in Ihrer Implementierung haben Sie nicht den Zugang zur Arbeitseinheit so. Was ich mache, ist ein IoC-Container und Dependency Injection, um damit umzugehen. Ich habe einen WCF-Dienst, der Unit of Work mit einem Repository-Muster gegen EF5 verwendet.

Sie können mehr über Repository-Muster, Arbeitseinheit lesen, und EF here aber im Grunde, was ich im Konstruktor meiner Dienstklasse I die Arbeitseinheit wie so injizieren: Ich

private readonly IUnitOfWork uow; 

    public LoanService(IUnitOfWork unitOfWork) 
    { 
     uow = unitOfWork; 
    } 

Dann kann uow.WhateverMethod in meinen Repos überall im Dienst verwenden. Ich benutze Ninject, um die Injektion von IUnitOfWork zu behandeln. Hoffe es hilft dir.