Jakie są plusy i minusy używania jednego lub wielu DbContext z EF?

Question

VS2013, kod EF6 pierwszy, MVC, (VB)

Chciałem lepiej zrozumieć plusy i minusy używania jednego kontekstu lub podziału DbSets na wiele kontekstów. Czytałem niektóre z dawnych postów SO na wielu DbContexts i naprawdę nie znalazłem tego, czego szukałem; kompleksowe oświadczenie o tym, kiedy i gdzie należy używać wielu DbContextów.

W przypadku pojedynczego użytkownika korzystającego z programu takiego jak Windows Forms na własnym sprzęcie, wydaje się, że nie ma powodu, aby mieć wiele kontekstów dla łatwości pracy z kodem.

W przypadku aplikacji internetowej, która uruchamia duży program biznesowy dla wielu firm, wydaje się, że wiele DbContextów ma kluczowe znaczenie dla bezpieczeństwa i administracji.

Ale chciałbym uzyskać potwierdzenie, jeśli dobrze myślę o tym pytaniu. Wszystko, co mogę myśleć o to, co następuje, ale jestem zupełnie nowy w tym środowisku:

Plusy jednym kontekście:

• Kodowanie ma tylko jeden kontekst do czynienia z
  • (Czy istnieją problemy z relacjami całej kontekstach?)
• migracje są łatwiejsze, ponieważ istnieje tylko jeden folder migracji i proces
• łatwiej uzyskać kompleksową d iagram skonstruowany w SSMS lub EDMX
  • (Link here uzyskania diagramy EDMX podczas korzystania pierwszy kod)

minusy jednym kontekście:

• bezpieczeństwa może być problemem dla wielu sieci klientów w aplikacji dla przedsiębiorstw
  • (Czy jest to problem dotyczący prostych witryn z prostymi uprawnieniami?)
• Niektórzy SO posty wydają się sugerować, czas reakcji jest kwestią
  • (Jaki jest mechanizm tutaj?)

To wszystko, co mam. Nie wiem wystarczająco dużo, aby w pełni zrozumieć obie strony i biorąc pod uwagę różne środowiska, w których możemy pracować, wydaje się, że odpowiedź na jeden lub wiele kontekstów będzie inna.

Pracuję obecnie nad stroną internetową, która będzie miała członkostwo, a także aplikację do pobrania, która będzie osobistą aplikacją działającą na sprzęcie użytkownika. W tym przypadku myślę, że jeden kontekst dla obu ma sens, ale zanim w to zagłębię się, chciałbym prosić o dyskusję na ten temat. Przypuszczam, że ci, którzy są nieco nowi w środowisku, będą nadal mieć te same pytania.

Zauważyłem również, że Microsoft uznał za stosowne dodać wiele możliwości kontekstowych do EF w EF6 i wyższych, więc wyraźnie muszą istnieć pewne środowiska programistyczne, które powodują istotne powody, by mieć wiele kontekstów.

Dzięki za wejście.

Pozdrawiam, Alan

Answer 1

Jedyny dobry powód, aby mieć wiele kontekstów, moim zdaniem, jeśli masz kilka baz w grze. Jedna aplikacja, z którą pracuję, ma na przykład 3 konteksty. Dwa konteksty dotyczą istniejących baz danych, za które aplikacja nie jest bezpośrednio odpowiedzialna, a trzeci to kontekst specyficzny dla aplikacji z migracjami.

Nie ma prawdziwej korzyści dla podziału kontekstu. Erik sugeruje, że duże konteksty mają problemy z wydajnością, ale pracowałem z jednym kontekstem z 50+ zestawami obiektów i nie zauważyłem żadnych problemów z wydajnością.

Jednak z drugiej strony, występują poważne przeszkody w pracy z wieloma kontekstami. Po pierwsze, tracisz umiejętność pracy z wieloma obiektami, chyba że wszystkie znajdują się w tym samym kontekście. Ponadto, wiele kontekstów ma tendencję do mylenia się z zielonymi deweloperami z powodu śledzenia obiektów obiektu Entity Framework. Na przykład, powiedzmy, że masz dwie jednostki, Foo i Bar, zarówno w oddzielnych kontekstach. Jeśli utworzono relację Bar na Foo:

public class Foo 
{ 
    public virtual Bar Bar { get; set; } 
} 

No, wiecie co? Zarówno , jak i isą teraz śledzone przez kontekst Foo. Jeśli następnie spróbujesz uruchomić migracje w obu kontekstach, dostaniesz błędy, ponieważ Bar jest zarządzane w dwóch, zliczanie, dwa konteksty.

Błędy takie jak te są absurdalnie łatwe do wykonania, a doprowadzisz do szału, starając się, aby wszystko było całkowicie wykluczone. Dodatkowo, moim argumentem było zawsze to, że jeśli masz w projekcie elementy, które możesz całkowicie wykluczyć z innych, to jest to argument dla całkowicie oddzielnego projektu, a nie tylko innego kontekstu.

Answer 2

Widziałem w komentarzach, o których wspomniałeś ucząc się Domain Driven Design. Jedną z koncepcji DDD jest Bounded Contexts (należy sprawdzić połączony zasób pod adresem bubble contexts, aby zobaczyć, jak radzić sobie z dwoma kontekstami, które współużytkują elementy).

Zmusza to do odwzorowania ograniczonych kontekstów za pomocą osobnego kontekstu DbContour dla każdego z nich. Są pewne pułapki, na które trzeba uważać, kiedy to robisz, ale stosowanie metody DDD powinno pomóc ci ich uniknąć. Podstawowym elementem są jednostki wspólne. Jeden kontekst powinien być odpowiedzialny za kontrolowanie cyklu życia współużytkowanych podmiotów, drugi powinien jedynie wysyłać zapytania do tych podmiotów i nie wprowadzać w nich żadnych zmian.

Oddzielenie domeny w ograniczone konteksty pozwoli łatwiej zarządzać dużą/złożoną domeną. Zapobiega także niepotrzebnemu ładowaniu części domeny, jeśli ich nie potrzebujesz (w architekturze SOA można wdrożyć każdy ograniczony kontekst autonomicznie jako usługę, którą Udi Dahan nazywa Autonomous Business Component).

Nie zalecałbym podziału, dopóki nie będziesz musiał. Na przykład wiele zespołów pracujących w różnych częściach domeny w tym samym czasie może stanowić dobrą okazję do podziału, ale w pewnym momencie na pewno będzie to miało sens.