È buona norma avere più classi XXX : DbContext per ogni sezione principale di un'applicazione Web (considerando che è una grande con almeno 50 tabelle nel suo database)? Ad esempio: MembershipContext, BlogContext, StoreContext, ecc. Oppure è più conveniente disporre di un singolo DatabaseContext per tutti gli elementi relativi all'accesso db.Più classi DbContext per una singola app Web. Bene o male?
L'utilizzo di più classi DbContext implica la complicazione delle transazioni incrociate (è possibile trovare una soluzione a questo problema sul web qui un esempio http://pastebin.com/YEDqyH0n) ma potrebbe essere giustificato. Tutto dipende dalla tua architettura e dalla separazione che vuoi progettare.
In ogni caso, è necessario esaminare i modelli Repository e UnitOfWork per avere uno strato di astrazione su come utilizzare DbContexts. Guarda qui: Multiple DbContexts in N-Tier Application e qui EF and repository pattern - ending up with multiple DbContexts in one controller - any issues (performance, data integrity)? se usi ASP.NET MVC.
Per 50 tabelle, penso che sia giustificato avere più DbContexts. Quindi consiglierei di usare più DbContexts. Ma dovresti avvolgerli usando i modelli Repository e UnitOfWork per essere indipendenti dall'attuale implementazione negli altri livelli (come questo puoi facilmente cambiare idea in seguito e usare solo un signle DbContext per esempio).
Spero che questo aiuti.
DbContext implementa già i modelli di repository e Unit-of-Work! –