Thiết kế kho lưu trữ cho DI (constructor injection) cho lớp dịch vụ

Question

Tôi đang xây dựng một ứng dụng MVC3, cố gắng sử dụng IoC và constructor injection. Cơ sở dữ liệu của tôi có (cho đến nay) khoảng 50 bảng. Tôi đang sử dụng mẫu EF4 (w/POCO T4) cho mã DAC của mình. Tôi đang sử dụng mẫu kho lưu trữ, và mỗi bảng có kho lưu trữ riêng của nó. Các lớp dịch vụ của tôi trong lớp dịch vụ của tôi được tiêm w/các kho lưu trữ này.

Sự cố: Các lớp dịch vụ của tôi đang phát triển về số lượng kho mà họ cần. Trong một số trường hợp, tôi đang tiếp cận 10 kho, và nó bắt đầu có mùi.

Có cách tiếp cận chung để thiết kế kho và các lớp dịch vụ sao cho các dịch vụ không yêu cầu nhiều kho lưu trữ không?

Dưới đây là suy nghĩ của tôi, tôi chỉ là không chắc chắn cái nào là đúng:

1) Đây là dấu hiệu tôi nên xem xét kết hợp/nhóm kho của tôi vào bộ phận liên quan của bảng, giảm số lượng hoặc kho phụ thuộc cho mỗi lớp dịch vụ. Tuy nhiên, vấn đề với cách tiếp cận này là nó sẽ sưng lên và làm phức tạp các kho lưu trữ của tôi, và sẽ giữ cho tôi không thể sử dụng một giao diện chung cho tất cả các kho lưu trữ (các phương thức chuẩn để truy xuất/cập nhật dữ liệu).

2) Đây là một dấu hiệu tôi nên cân nhắc việc chia nhỏ các dịch vụ của mình thành các nhóm dựa trên các kho lưu trữ của tôi (bảng). Vấn đề với điều này là một số phương pháp dịch vụ của tôi chia sẻ việc triển khai phổ biến và phá vỡ các phương thức này trên các lớp có thể làm phức tạp các phụ thuộc của tôi.

3) Đây là dấu hiệu cho thấy tôi không biết mình đang làm gì và có điều gì đó sai về cơ bản mà tôi thậm chí không thể thấy.

CẬP NHẬT: Để biết cách triển khai EF4 và kho lưu trữ, hãy xem this sample app trên codeplex (Tôi đã sử dụng version 1). Tuy nhiên, nhìn vào một số ý kiến ​​ở đó (và ở đây), có vẻ như tôi cần phải đọc nhiều hơn một chút để đảm bảo đây là tuyến đường tôi muốn thực hiện - có vẻ như nó không thể như vậy.

Answer 1

Chandermani is right rằng một số bảng của bạn có thể không phải là các lớp miền chính. Điều này có nghĩa là bạn sẽ không bao giờ tìm kiếm dữ liệu đó ngoại trừ về một loại thực thể cha. Trong những trường hợp đó, bạn có thể tham khảo chúng là "các loại phức tạp" hơn là các thực thể toàn diện và EF sẽ vẫn chăm sóc bạn.

Tôi đang sử dụng mô hình kho, và mỗi bảng có kho riêng của mình

tôi hy vọng bạn không viết những bản thân từ đầu.

EF 4.1 đã triển khai the Repository Pattern (DbSet) và the Unit of Work pattern (DbContext). Các phiên bản cũ hơn cũng vậy, mặc dù mẫu DbContext có thể dễ dàng được tinh chỉnh để cung cấp triển khai thực hiện rõ ràng bằng cách thay đổi các thuộc tính đó thành một số IDbSet.

Tôi đã xem một số bài viết hướng dẫn mà mọi người vẫn viết bài của riêng họ. Thật lạ lùng với tôi, bởi vì họ thường không cung cấp một sự biện minh, khác với thực tế là họ đang "thực hiện mẫu lưu trữ".

Viết trình bao bọc cho các kho lưu trữ này cho các phương thức truy cập như FindById giúp truy cập dễ dàng hơn một chút, nhưng như bạn đã thấy là một số lượng lớn nỗ lực có khả năng hoàn vốn ít. Cá nhân, trừ khi tôi thấy rằng có logic miền thú vị hoặc các truy vấn phức tạp được đóng gói, tôi thậm chí không bận tâm và chỉ sử dụng Linq trực tiếp với IDbSet.

Các lớp dịch vụ của tôi trong lớp dịch vụ của tôi được tiêm w/các kho lưu trữ này.

Ngay cả khi bạn chọn sử dụng trình bao bọc truy vấn tùy chỉnh, bạn có thể chọn chỉ cần tiêm DbContext và để mã dịch vụ khởi tạo trình bao bọc cần. Bạn vẫn có thể giả lập lớp truy cập dữ liệu của mình, bạn sẽ không thể giả lập mã trình bao bọc. Tôi vẫn khuyên bạn nên tiêm ít hơn chung chung mặc dù, bởi vì thực hiện phức tạp là chính xác loại điều bạn muốn để có thể yếu tố ra trong bảo trì, hoặc thay thế bằng mocks.

Answer 2

Nếu bạn nhìn vào mẫu DDD Aggregate Root và cố gắng xem dữ liệu của bạn trong phối cảnh này, bạn sẽ nhận ra rằng nhiều bảng không có sự tồn tại độc lập. Dữ liệu của họ chỉ hợp lệ trong ngữ cảnh của cha mẹ họ. Hầu hết các hoạt động trên chúng đòi hỏi bạn phải có được cha mẹ là tốt. Nếu bạn có thể nhóm các bảng như vậy và tìm thấy thực thể cha mẹ \ kho lưu trữ tất cả các kho lưu trữ con khác có thể được gỡ bỏ. Sự phức tạp của việc liên kết cha mẹ mà cho đến bây giờ bạn sẽ làm trong lớp nghiệp vụ của bạn (giả sử bạn đang truy xuất cha và con bằng cách sử dụng repo độc lập) sẽ không được chuyển sang DAL

Giao diện Dịch vụ Tái cấu trúc cũng là một lựa chọn khả thi, và bất kỳ chức năng phổ biến nào cũng có thể được chuyển thành lớp cơ sở và \ hoặc có thể được định nghĩa là dịch vụ được tất cả các dịch vụ hiện có của bạn sử dụng (A A và A)

Answer 3

@Chandermani có điểm tốt về nguồn gốc tổng hợp. Các kho lưu trữ không nên, cần có ánh xạ 1: 1 cho các bảng.

Nhận số lượng lớn các gói phụ thuộc được chèn vào là dấu hiệu tốt mà dịch vụ của bạn đang thực hiện quá nhiều. Thực hiện theo nguyên tắc về trách nhiệm duy nhất và tái cấu trúc chúng thành các phần dễ quản lý hơn.

Answer 4

dịch vụ của bạn có được viết cho tất cả các kho lưu trữ không? tôi thấy rằng các dịch vụ của tôi xếp hàng khá chặt chẽ với các kho lưu trữ, rằng chúng cung cấp logic nghiệp vụ xung quanh các hoạt động CRUD mà kho lưu trữ.