Nhiều lớp DataContext có phù hợp không?

Question

Để sử dụng đầy đủ LinqToSql trong ứng dụng ASP.net 3.5, cần tạo DataContextclasses (thường được thực hiện bằng cách sử dụng trình thiết kế trong VS 2008). Từ quan điểm UI, DataContext là một thiết kế của các phần cơ sở dữ liệu của bạn mà bạn muốn hiển thị thông qua LinqToSql và không thể thiếu trong việc thiết lập các tính năng ORM của LinqToSql.

Câu hỏi của tôi là: Tôi đang thiết lập một dự án sử dụng cơ sở dữ liệu lớn, nơi tất cả các bảng được kết nối với nhau theo một cách nào đó thông qua Khóa ngoại. Độ nghiêng đầu tiên của tôi là tạo một lớp DataContext khổng lồ mô hình hóa toàn bộ cơ sở dữ liệu. Bằng cách đó tôi có thể trong lý thuyết (mặc dù tôi không biết điều này có cần thiết trong thực tế hay không) sử dụng các kết nối Khóa ngoài được tạo thông qua LINQToSql để dễ dàng chuyển giữa các đối tượng liên quan trong mã của tôi, chèn các đối tượng liên quan, v.v.

Tuy nhiên, sau khi đưa ra một số suy nghĩ, bây giờ tôi nghĩ rằng việc tạo nhiều lớp DataContext có ý nghĩa hơn, mỗi lớp liên quan đến một không gian tên cụ thể hoặc phần tương quan logic trong cơ sở dữ liệu của tôi. Mối quan tâm chính của tôi là instantiating và xử lý một lớp DataContext khổng lồ tất cả các thời gian cho các hoạt động cá nhân có liên quan đến các khu vực cụ thể của cơ sở dữ liệu sẽ áp đặt một áp đặt không cần thiết về tài nguyên ứng dụng. Ngoài ra, việc tạo và quản lý các tệp DataContext nhỏ hơn dễ dàng hơn một tệp lớn. Điều mà tôi sẽ mất là sẽ có một số phần xa của cơ sở dữ liệu không thể điều hướng qua LinqToSql (mặc dù một chuỗi các mối quan hệ kết nối chúng trong cơ sở dữ liệu thực tế). Ngoài ra, sẽ có một số lớp bảng sẽ tồn tại trong nhiều hơn một DataContext.

Bất kỳ suy nghĩ hoặc kinh nghiệm nào về việc liệu nhiều DataContexts (tương ứng với không gian tên DB) có phù hợp thay cho (hoặc ngoài) một lớp DataContext rất lớn (tương ứng với toàn bộ DB) không?

Answer 1

Tôi không đồng ý với câu trả lời của John. DataContext (hoặc LINQ to Entities ObjectContext) là một "đơn vị công việc" hơn là kết nối. Nó quản lý theo dõi thay đổi, v.v.Xem bài viết trên blog này để xem mô tả:

Lifetime of a LINQ to SQL DataContext

Bốn điểm chính của bài viết trên blog này được rằng DataContext:

1. là lý tưởng cho một "đơn vị làm việc" tiếp cận
2. Cũng được thiết kế cho hoạt động máy chủ "không quốc tịch"
3. Không được thiết kế cho Sử dụng lâu dài

4. Should be used very carefully after 
   any SumbitChanges() operation. 
   

Xét rằng, tôi không nghĩ rằng sử dụng nhiều hơn một DataContext sẽ làm bất cứ harm- trên thực tế, tạo DataContexts khác nhau với nhiều loại công việc khác nhau sẽ giúp làm cho impelmentation LinqToSql bạn usuable hơn và có tổ chức. Nhược điểm duy nhất là bạn sẽ không thể sử dụng sqlmetal để tự động tạo ra dmbl của bạn.

Answer 2

Theo kinh nghiệm của tôi với LINQ to SQL và LINQ to Entities, DataContext đồng nghĩa với kết nối với cơ sở dữ liệu. Vì vậy, nếu bạn đã sử dụng nhiều cửa hàng dữ liệu, bạn sẽ cần phải sử dụng nhiều DataContexts. Phản ứng ruột của tôi là bạn sẽ không nhận thấy phần lớn sự chậm lại với một DataContext bao gồm một số lượng lớn các bảng. Tuy nhiên, nếu bạn đã luôn có thể tách cơ sở dữ liệu một cách hợp lý tại các điểm mà bạn có thể tách các bảng không có bất kỳ mối quan hệ nào với các nhóm bảng khác và tạo nhiều bối cảnh.

Answer 3

Tôi đã tranh luận về cùng một câu hỏi trong khi đặt LINQ to SQL phù hợp trên một DB cũ. Cơ sở dữ liệu của chúng tôi là một chút của một whopper (150 bảng) và sau khi một số suy nghĩ và thử nghiệm tôi đã chọn sử dụng nhiều DataContexts. Cho dù điều này được coi là một mô hình chống vẫn còn để được nhìn thấy, nhưng bây giờ nó làm cho cuộc sống quản lý.

Answer 4

Tôi nghĩ John là chính xác.

"mối quan tâm chính của tôi là instantiating và xử lý một lớp DataContext lớn tất cả các thời gian cho các hoạt động cá nhân có liên quan đến lĩnh vực cụ thể của cơ sở dữ liệu sẽ được áp đặt một áp đặt không cần thiết về tài nguyên ứng dụng"

Làm thế nào để bạn ủng hộ mà tuyên bố? Thử nghiệm của bạn cho thấy rằng một DataContext lớn là một nút cổ chai hiệu suất là gì? Có nhiều datacontexts là rất nhiều giống như có nhiều cơ sở dữ liệu và có ý nghĩa trong các kịch bản tương tự, đó là, hầu như không bao giờ. Nếu bạn đang làm việc với nhiều datacontexts, bạn cần phải theo dõi các đối tượng nào thuộc về datacontext nào và bạn không thể liên kết các đối tượng không có cùng ngữ cảnh dữ liệu. Đó là một mùi thiết kế tốn kém không có lợi ích thực sự.

@Evan "DataContext (hoặc LINQ to Entities ObjectContext) là một" đơn vị công việc "hơn là kết nối" Đó là lý do tại sao bạn không nên có nhiều hơn một datacontext. Tại sao bạn muốn nhiều hơn một "đơn vị công việc" tại một thời điểm?

Answer 5

Tôi phải không đồng ý với câu trả lời được chấp nhận. Trong câu hỏi đặt ra, hệ thống có một cơ sở dữ liệu lớn duy nhất với mối quan hệ mạnh mẽ nước ngoài quan trọng giữa hầu hết các bảng (cũng là trường hợp tôi làm việc). Trong trường hợp này, chia nhỏ nó thành các DataContexts nhỏ hơn (DC) có hai nhược điểm ngay lập tức và chính (cả hai được đề cập bởi câu hỏi):

1. Bạn mất mối quan hệ giữa một số bảng. Bạn có thể cố gắng chọn ranh giới DC một cách khôn ngoan, nhưng cuối cùng bạn sẽ gặp phải một tình huống rất thuận lợi khi sử dụng mối quan hệ từ một bảng trong một DC tới bảng khác và bạn sẽ không thể.
2. Một số bảng có thể xuất hiện trong nhiều DC. Điều này có nghĩa rằng nếu bạn muốn thêm các phương thức trợ giúp theo bảng cụ thể, logic nghiệp vụ hoặc mã khác trong các lớp một phần, các loại sẽ không tương thích trên DC. Bạn có thể làm việc xung quanh điều này bằng cách kế thừa từng lớp thực thể từ lớp cơ sở cụ thể của riêng nó, điều này trở nên lộn xộn. Ngoài ra, các thay đổi lược đồ sẽ phải được nhân đôi trên nhiều DC.

Bây giờ, đó là những hạn chế đáng kể. Có lợi thế đủ lớn để vượt qua chúng?Câu hỏi đặt ra đề cập đến hiệu suất:

mối quan tâm chính của tôi là instantiating và xử lý một khổng lồ lớp DataContext tất cả các thời gian cho các hoạt động cá nhân có liên quan cho các khu vực cụ thể của cơ sở dữ liệu sẽ được áp đặt một áp đặt không cần thiết về tài nguyên ứng dụng.

Thực ra, một DC lớn mất nhiều thời gian hơn để nhanh chóng hoặc sử dụng trong một đơn vị công việc điển hình. Trên thực tế, after the first instance is created in a running process, subsequent copies of the same DC can be created almost instantaneously.

Lợi thế thực sự duy nhất từ ​​nhiều DC cho một cơ sở dữ liệu lớn duy nhất với các mối quan hệ khóa ngoại toàn diện là bạn có thể chia nhỏ mã của bạn tốt hơn một chút. Nhưng bạn đã có thể làm điều này với các lớp học một phần.

Ngoài ra, đơn vị khái niệm công việc không thực sự liên quan đến câu hỏi ban đầu. Đơn vị của công việc thường đề cập đến bao nhiêu một công việc một đơn DC dụ đang làm, không bao nhiêu công việc một DC lớp là khả năng làm.