2013-01-11 10 views
6

Zabrakło mi trochę problemu z EF poszukuje najlepszych praktyk dla tego problemu:jednostka pracy, Entity Framework DBContext Zakres

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); 

} 

W metodzie TestEntityFramework_UOWImplementation(), jego porządku, zadzwoń, stwórz zakres mojej jednostki pracy ... i utwórz w niej repozytorium.

Ale kiedy chcę uzyskaćMaterials() jak poniżej .. Nie mam dostępu do jednostki pracy lub repozytorium, chyba że faktycznie przekazać go jako parametr! To zdecydowanie nie jest szczególnie miłe.

Jak ludzie radzą sobie z tym problemem?

Z góry dziękuję!

Neil

+1

Gdyby nie 'GetMaterial' być metoda przykład w Klasa "MaterialRepository"? –

+0

to dobry punkt! :), ale mówię, że był jakiś jeden przypadek, w którym chciałbyś zrobić Where() .. przypuszczam, że byłyby one również w repozytorium. Dzięki! teraz, kiedy widzę, że to jest napisane w sposób oczywisty :) –

+0

Właściwie, powiedzmy, że było kilka zapytań repo. czy nie sądzisz, że kiedykolwiek miałby miejsce przypadek, w którym kwerendy byłyby wykonywane poza repozytorium? Powiedzmy, że miałem metodę o nazwie CalculateMaterialPrices(), która wymagała listy materiałów do obliczenia.Czy możesz nazwać metodę repo GetMaterials() w metodzie TestEntityFramework_UOWImplementation() lub w metodzie CalculateMaterialPrices(), jeśli to drugie, w jaki sposób uzyskasz dostęp do repo? czy nie jestem tu na dobrej drodze! –

Odpowiedz

0

Jeśli ktoś szukał sposobu na obejście tego, zrobiłem coś nieco innego.

Użyłem struktury Dependency Injection (StructureMap) do obsługi wszystkich DI, więc za każdym razem, gdy tworzę instancję, pobierze DBContext z Service Locator z StructureMap. Ustanawiam również zakres dbcontext na czas żądania z serwera.

Zaletą jest to, że za każdym razem, gdy pobierze lub wstrzyknę DBContext, pobierze ten sam kontekst na czas trwania zapytania, co oznacza, że ​​mogę go używać na wiele metod i klas! Podaję typ interfejsu jako ogólny parametr konstruktora, co oznacza, że ​​mogę wskazać repo jako różne konteksty. Przydatne w aplikacjach, w których istnieje wiele kontekstów dbcontext.

Repo Konstruktor Np

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

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

Zastosowanie:

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

i zależność struktura mapa wygląda następująco:

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

im zainteresowany opiniami !! –

3

W implementacji przyzwyczajenie mieć dostęp do jednostki pracy takiego. W tym celu używam kontenera IoC i Dependency Injection. Mam usługę WCF, która używa jednostki pracy z wzorem repozytorium przeciwko EF5.

Możesz przeczytać więcej o repozytorium deseniu, jednostki pracy i EF here ale w zasadzie to, co robię jest w konstruktorze moje klasy serwisowej I wstrzyknąć jednostka pracy tak:

private readonly IUnitOfWork uow; 

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

potem może używać uow.WhateverMethod w moich repozytoriach w dowolnym miejscu usługi. Używam Ninject do obsługi wtrysku IUnitOfWork. Mam nadzieję, że ci to pomoże.

Powiązane problemy