Ưu và nhược điểm của việc sử dụng một hoặc nhiều DbContext với EF là gì?

Question

VS2013, mã EF6 trước, MVC, (VB)

Tôi muốn hiểu rõ hơn về ưu và nhược điểm của việc sử dụng ngữ cảnh đơn lẻ hoặc chia DbSets thành nhiều ngữ cảnh. Tôi đã đọc qua một số bài viết SO cũ trên nhiều DbContexts và không thực sự tìm thấy những gì tôi đang tìm kiếm; một tuyên bố toàn diện về thời gian và địa điểm sử dụng hoặc không sử dụng nhiều DbContexts.

Trong trường hợp một người dùng đang chạy một chương trình như Windows Forms trên phần cứng của riêng họ, có vẻ như không có lý do gì để có nhiều bối cảnh dễ làm việc với mã.

Trong trường hợp ứng dụng web chạy chương trình kinh doanh chính cho nhiều doanh nghiệp, có vẻ như nhiều DbContexts là điều cần thiết cho bảo mật và quản trị.

Nhưng tôi muốn nhận được xác nhận nếu tôi đang suy nghĩ về câu hỏi này một cách chính xác. Tất cả tôi có thể nghĩ đến là sau đây, nhưng sau đó tôi là khá mới với môi trường này:

Ưu điểm của một bối cảnh duy nhất:

• chỉ Mã hóa có một bối cảnh duy nhất để đối phó với
  • (có vấn đề với các mối quan hệ giữa bối cảnh?)
• Migrations là dễ dàng hơn vì chỉ có một thư mục di cư và quá trình
• dễ dàng hơn để có được một d toàn diện iagram xây dựng trong SSMS hoặc EDMX
  • (Link here để nhận sơ đồ EDMX khi sử dụng mã đầu tiên)

Nhược điểm của một bối cảnh duy nhất:

• an ninh có thể là một vấn đề đối với nhiều web khách hàng trên ứng dụng doanh nghiệp
  • (Đây có phải là vấn đề cho các trang web đơn giản có tư cách thành viên đơn giản không?)
• Một số SO bài viết dường như cho thấy thời gian đáp ứng là một vấn đề
  • (cơ chế này là gì đây?)

Đó là tất cả tôi có. Tôi không biết đủ để hiểu đầy đủ về hai mặt, và đưa ra các môi trường khác nhau mà chúng ta có thể làm việc, dường như câu trả lời cho một hoặc nhiều bối cảnh sẽ khác nhau.

Tôi hiện đang làm việc trên một trang web sẽ có tư cách thành viên và cũng là ứng dụng có thể tải xuống sẽ là ứng dụng cá nhân chạy trên phần cứng của người dùng. Trong trường hợp này, tôi nghĩ rằng một bối cảnh duy nhất cho cả hai có ý nghĩa, nhưng trước khi tôi nhận được quá sâu vào nó, tôi mặc dù tôi sẽ yêu cầu một số cuộc thảo luận về điều này. Tôi cho rằng những người khác có phần mới với môi trường sẽ tiếp tục có cùng câu hỏi.Tôi cũng lưu ý rằng Microsoft thấy phù hợp để bổ sung nhiều khả năng ngữ cảnh cho EF trong EF6 và cao hơn, vì vậy rõ ràng phải có một số môi trường lập trình đưa ra lý do thuyết phục để có nhiều bối cảnh.

Cảm ơn bạn đã nhập.

Best Regards, Alan

Answer 1

duy nhất lý do chính đáng để có nhiều bối cảnh, theo ý kiến ​​của tôi, là nếu bạn có nhiều cơ sở dữ liệu trong vở kịch. Ví dụ, một ứng dụng tôi làm việc có 3 ngữ cảnh. Hai ngữ cảnh là dành cho các cơ sở dữ liệu hiện có mà ứng dụng không chịu trách nhiệm trực tiếp, trong khi thứ ba là ngữ cảnh ứng dụng cụ thể với việc di chuyển.

Không có lợi ích thực sự nào khi tách một ngữ cảnh. Erik gợi ý rằng những bối cảnh lớn có vấn đề về hiệu suất, nhưng tôi đã làm việc với một bối cảnh đơn lẻ với hơn 50 bộ đối tượng trong đó, và đã nhận thấy không có vấn đề về hiệu suất nào cả.

Tuy nhiên, ở mặt bên kia, có những bất lợi thực sự để làm việc với nhiều ngữ cảnh. Đối với một, bạn mất khả năng làm việc với nhiều đối tượng liền mạch trừ khi tất cả chúng đều nằm trong cùng một ngữ cảnh. Ngoài ra, nhiều bối cảnh có xu hướng gây nhầm lẫn giữa các nhà phát triển xanh vì tính năng theo dõi đồ thị đối tượng của Entity Framework. Ví dụ: giả sử bạn có hai thực thể, Foo và Bar, cả hai trong ngữ cảnh riêng biệt. Nếu bạn đã tạo một mối quan hệ để Bar trên Foo:

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

Vâng, đoán những gì? Cả hai FoovàBar hiện được theo dõi bởi ngữ cảnh của Foo. Nếu sau đó bạn cố gắng chạy di chuyển trên cả hai ngữ cảnh, bạn sẽ gặp lỗi vì Bar được quản lý theo hai, đếm 'em, hai ngữ cảnh.

Những sai lầm như thế này rất dễ gây ra, và bạn sẽ tự lái mình để cố gắng giữ cho mọi thứ hoàn toàn bị loại trừ. Hơn nữa, lập luận của tôi luôn là nếu bạn có các thực thể trong dự án của mình mà bạn hoàn toàn có thể loại trừ khỏi những người khác, thì đó là một đối số cho một dự án hoàn toàn riêng biệt, không chỉ là một ngữ cảnh khác.

Answer 2

Tôi đã thấy trong các nhận xét mà bạn đã đề cập đến việc học Thiết kế theo hướng miền. Một trong các khái niệm trong DDD là của Bounded Contexts (hãy nhớ xem tài nguyên được liên kết trên bubble contexts để xem cách xử lý hai bối cảnh chia sẻ Thực thể).

Nó làm cho tuyệt đối cảm giác ánh xạ ngữ cảnh bị chặn của bạn bằng cách sử dụng DbContext riêng biệt cho từng ngữ cảnh. Có một số gotchas mà bạn cần phải cảnh giác khi làm điều này nhưng theo một cách tiếp cận DDD sẽ giúp bạn tránh chúng. Mục chính là các thực thể được chia sẻ. Một ngữ cảnh phải chịu trách nhiệm kiểm soát vòng đời của các thực thể được chia sẻ, người kia chỉ nên truy vấn các thực thể đó và không thực hiện bất kỳ thay đổi nào đối với chúng.

Tách miền của bạn thành các ngữ cảnh bị chặn sẽ cho phép bạn dễ dàng quản lý miền lớn/phức tạp hơn. Nó cũng tránh các phần tải của tên miền không cần thiết nếu bạn không cần chúng (trong một SOA, bạn có thể triển khai từng ngữ cảnh được ràng buộc một cách tự động như một dịch vụ mà Udi Dahan gọi là Autonomous Business Component).

Tôi sẽ không ủng hộ việc chia nhỏ cho đến khi bạn phải làm vậy. Ví dụ: nhiều nhóm làm việc với các phần khác nhau của miền cùng một lúc có thể là cơ hội tốt để chia nhỏ nhưng tại một thời điểm nào đó, điều đó chắc chắn sẽ có ý nghĩa để thực hiện việc đó.