¿Es una buena práctica tener múltiples clases XXX : DbContext para cada sección principal de una aplicación web (considerando que es una gran con al menos 50 tablas en su base de datos)? Por ejemplo: MembershipContext, BlogContext, StoreContext, etc. O es más conveniente tener un solo DatabaseContext para todas las cosas relacionadas con el acceso a db.Múltiples clases de DbContext para una sola aplicación web. ¿Bueno o malo?
El uso de varias clases de DbContext implica complicar las transacciones cruzadas (aquí puede encontrar una solución a este problema en la web, por ejemplo, http://pastebin.com/YEDqyH0n) pero puede estar justificado. Todo depende de su arquitectura y la separación que desee diseñar.
De todos modos, debe mirar los patrones Repository y UnitOfWork para tener una capa de la descripción de cómo usar sus DbContexts. Mire aquí: Multiple DbContexts in N-Tier Application y aquí EF and repository pattern - ending up with multiple DbContexts in one controller - any issues (performance, data integrity)? si usa ASP.NET MVC.
Para 50 tablas, creo que se justifica tener múltiples DbContexts. Así que recomendaría usar múltiples DbContexts. Pero debe envolverlos usando los patrones Repository y UnitOfWork para que sean independientes de la implementación real en las otras capas (así podría cambiar de opinión más adelante y solo usar un signle DbContext por ejemplo).
Espero que ayude.
¡DbContext ya implementa los patrones de repositorio y unidad de trabajo! –