MVC 3 + EF 4.1Jaki jest najlepszy sposób tworzenia i usuwania DbContext w MVC?
mam wybór między dwoma podejściami do czynienia z DbContext:
- instancji w
Application_BeginRequest
, umieścić go wHttpContext.Current.Items
i rozporządzania wApplication_EndRequest
. - Tworzenie jednorazowy UnitOfWork (kindof wrapper dla
DbContext
) i rozpoczęcie każdego działania kontrolera zusing(var unitOfWork = new UnitOfWork()) { ... }
Podziel się doświadczeniem proszę: Które jeden wolisz? jakie są plusy i minusy dla każdego podejścia?
Zastosowanie metody blokowej ma pewne wady. Powoduje wiele podróży w obie strony do bazy danych i nadużycia transakcji w ramach Entity. odnieść się do http://ayende.com/blog/4775/new-profiler-feature-avoid-writes-from-multiple-sessions-in-tame-reame-request – marvelTracker
Dlaczego powoduje więcej wizyt w obie strony?Jedno żądanie http powinno w większości przypadków uruchomić jedną akcję, więc jeśli zawiniesz cały kod akcji do tego bloku, nie będzie więcej żądań bazy danych w porównaniu z pierwszym podejściem. Inną rzeczą przy podejściu "na działanie" jest to, że powinieneś zawsze być świadomym zakresu, w jakim baza danych może zostać przywołana i odpowiednio ustawić blok. Na przykład, jeśli twój model zawiera pewną kolekcję, która ma być leniwą ładowaną w czasie Wyświetlanie widoku, powracanie widoku View (Model) powinno znajdować się wewnątrz bloku. – YMC
Jeśli używasz DbContext w wrapperu warstwy kontrolera, UnitOfWork tworzy silne uzależnienie od warstwy interfejsu i podejścia do bazy danych. Następnie potrzebujesz warstwy serwisowej i warstwy repozytorium. Następnie, jeśli twoje repozytoria mają oddzielne UnitOfWork z użyciem bloków, które będą stanowić problem. ponieważ każde repozytorium tworzy transakcje i niepotrzebne obie strony w bazie danych. Zobacz powyższy link, aby uzyskać więcej szczegółów. jeśli masz pewność co do jednego zgłoszenia serwisowego na żądanie, możesz użyć unitofwork wewnątrz metody serwisowej. Jednak nie jest to gwarancja. – marvelTracker