Czy dobrą praktyką jest posiadanie wielu klas XXX : DbContext dla każdej głównej sekcji aplikacji internetowej (biorąc pod uwagę, że jest duża z co najmniej 50 tabelami w swojej bazie danych)? Na przykład: MembershipContext, BlogContext, StoreContext itp. Lub wygodniej jest mieć pojedyncze DatabaseContext dla wszystkich rzeczy związanych z dostępem do db.Wiele klas DbContext dla pojedynczej aplikacji internetowej. Dobry czy zły?
Używanie wielu klas DbContext implikuje skomplikowane transakcje krzyżowe (tutaj można znaleźć rozwiązanie tego problemu w Internecie, na przykład http://pastebin.com/YEDqyH0n), ale może być uzasadnione. Wszystko zależy od architektury i separacji, którą chcesz zaprojektować.
W każdym razie powinieneś spojrzeć na schematy Repozytorium i UnitOfWork, aby mieć warstwę abstrakcji, jak korzystać z DbContexts. Zajrzyj tutaj: Multiple DbContexts in N-Tier Application i tutaj EF and repository pattern - ending up with multiple DbContexts in one controller - any issues (performance, data integrity)?, jeśli używasz ASP.NET MVC.
Dla 50 tabel myślę, że może być uzasadnione posiadanie wielu DbContextów. Polecam więc używanie wielu DbContextów. Ale powinieneś owijać je za pomocą wzorców Repozytorium i UnitOfWork, aby były niezależne od rzeczywistej implementacji w innych warstwach (tak jak można później łatwo zmienić zdanie i używać tylko znaku DbContext).
Mam nadzieję, że to pomaga.
Kontekst DbContext już implementuje schematy repozytoriów i jednostek pracy! –