Thực tiễn tốt là có nhiều lớp XXX : DbContext cho mỗi phần chính của ứng dụng web (xem đây là một phần lớn có ít nhất 50 bảng trong cơ sở dữ liệu của nó) không? Ví dụ: MembershipContext, BlogContext, StoreContext vv Hoặc thuận tiện hơn để có một đơn DatabaseContext cho tất cả các công cụ liên quan đến truy cập db.Nhiều lớp DbContext cho một ứng dụng web duy nhất. Tốt hay xấu?
Sử dụng nhiều lớp DbContext ngụ ý làm phức tạp các giao dịch chéo (bạn có thể tìm giải pháp cho vấn đề này trên web ở đây ví dụ http://pastebin.com/YEDqyH0n) nhưng có thể được biện minh. Tất cả phụ thuộc vào kiến trúc của bạn và sự tách biệt mà bạn muốn thiết kế.
Dù sao thì bạn cũng nên xem xét các mẫu Kho lưu trữ và UnitOfWork để có một lớp tóm tắt về cách sử dụng DbContexts của bạn. Hãy xem tại đây: Multiple DbContexts in N-Tier Application và tại đây EF and repository pattern - ending up with multiple DbContexts in one controller - any issues (performance, data integrity)? nếu bạn sử dụng ASP.NET MVC.
Đối với 50 bảng, tôi cho rằng có thể hợp lý để có nhiều DbContexts. Vì vậy, tôi khuyên bạn nên sử dụng nhiều DbContexts. Nhưng bạn nên bọc chúng bằng cách sử dụng các mẫu Repository và UnitOfWork để độc lập với việc thực hiện thực tế trong các lớp khác (như thế này bạn có thể dễ dàng thay đổi ý định của bạn sau này và chỉ sử dụng một DbContext signle chẳng hạn).
Tôi hy vọng điều đó sẽ hữu ích.
DbContext đã triển khai các mẫu Kho lưu trữ và Đơn vị công việc! –