Mẫu lưu trữ so với đối tượng kinh doanh "thông minh"

Question

Tôi thấy hai "trường phái suy nghĩ" chính khi tạo ra các ứng dụng trên toàn doanh nghiệp có quy mô lớn trên .NET (Winforms, WPF, ASP.NET).

Một số người sử dụng "mẫu lưu trữ" sử dụng kho lưu trữ biết cách tìm nạp, chèn, cập nhật và xóa đối tượng. Những đồ vật đó khá "ngu ngốc" ở chỗ chúng không nhất thiết phải chứa rất nhiều logic - ví dụ: chúng có ít hoặc nhiều đối tượng chuyển dữ liệu.

Trại khác sử dụng những gì tôi gọi là đối tượng kinh doanh "thông minh" biết cách tải bản thân và thường có phương thức Save(), có thể Update() hoặc thậm chí Delete(). Ở đây bạn thực sự không cần bất kỳ kho lưu trữ nào - bản thân các đối tượng biết cách tải và lưu bản thân.

Câu hỏi lớn là: bạn sử dụng hoặc thích điều gì? Và tại sao?

Bạn có sử dụng cùng một cách tiếp cận trong tất cả các ứng dụng của mình hay bạn có bất kỳ tiêu chí cụ thể nào khi chọn một cách tiếp cận khác không? Nếu vậy - các tiêu chí đó là gì?

Tôi không cố gắng bắt đầu một cuộc chiến tranh ở đây - chỉ cần cố gắng tìm hiểu xem mọi người nghĩ gì về điều này và ý kiến ​​của bạn là gì và tại sao bạn sử dụng một (hoặc cả hai mẫu).

Cảm ơn mọi đầu vào xây dựng!

Answer 1

Tôi sử dụng mẫu kho lưu trữ vì Nguyên tắc về trách nhiệm duy nhất. Tôi không muốn mỗi đối tượng riêng lẻ phải biết cách lưu, cập nhật, xóa chính nó, khi điều này có thể được xử lý bởi một kho chung chung duy nhất

Answer 2

Mẫu kho lưu trữ không cần thiết dẫn đến các đối tượng câm. Nếu các đối tượng không có logic bên ngoài Lưu/Cập nhật, có thể bạn đang làm quá nhiều bên ngoài đối tượng.

Ý tưởng, bạn không bao giờ nên sử dụng thuộc tính để lấy dữ liệu từ đối tượng, tính toán mọi thứ và đưa dữ liệu trở lại trong đối tượng. Đây là một sự phá vỡ đóng gói.

Vì vậy, các đối tượng không nên thiếu máu ngoại trừ nếu bạn sử dụng các đối tượng DTO đơn giản với các hoạt động CRUD.

Sau đó, tách các mối quan ngại về sự kiên trì khỏi các mối quan tâm đối tượng của bạn là một cách tốt để có trách nhiệm duy nhất.

Answer 3

Tôi cho rằng tác dụng phụ quan trọng nhất của việc sử dụng mẫu Kho lưu trữ so với mẫu ActiveRecord là kiểm tra và mở rộng.

Nếu không có đối tượng ActiveRecord chứa chính kho lưu trữ, bạn sẽ cách ly dữ liệu trong trường hợp thử nghiệm của bạn như thế nào? Bạn có thể không thực sự giả mạo hoặc giả lập nó một cách dễ dàng. Bên cạnh việc thử nghiệm nó cũng sẽ khó khăn hơn nhiều trong việc trao đổi các công nghệ truy cập dữ liệu, ví dụ từ Linq-to-SQL sang NHibernate hoặc EntityFramework (mặc dù điều này không xảy ra thường xuyên thừa nhận).

Answer 4

Dưới đây là hai bài viết thú vị Tôi đã xem qua

Repository-is-the-new-singleton

The DAL should go all the way to UI

Answer 5

Nó thực sự phụ thuộc vào nhu cầu của các ứng dụng, nhưng khi giao dịch với một mô hình kinh doanh phức tạp, tôi thích ActiveRecord.Tôi có thể đóng gói (và kiểm tra) logic kinh doanh tất cả ở một nơi.

Hầu hết ORM (EF, nHibernate, v.v.) đóng vai trò là Kho lưu trữ của bạn. Nhiều người xem xét một lớp trên đầu trang của một ORM đóng gói tất cả các tương tác dữ liệu như một Repository, mà tôi tin là không chính xác. Theo Martin Fowler, một Repository gói gọn truy cập dữ liệu như một bộ sưu tập. Vì vậy, có phương pháp riêng lẻ cho tất cả truy xuất/đột biến dữ liệu có thể đang sử dụng Trình lập bản đồ dữ liệu hoặc Đối tượng truy cập dữ liệu.

Sử dụng ActiveRecord, tôi muốn có lớp cơ sở "Thực thể". Tôi thường sử dụng một ORM (kho lưu trữ) với lớp cơ sở này, vì vậy tất cả các thực thể của tôi có một phương thức GetById, AsQueryable, Save và Delete.

Nếu tôi đang sử dụng Kiến trúc hướng dịch vụ, tôi sẽ sử dụng kho lưu trữ (kho lưu trữ dữ liệu trực tiếp hoặc ORM) và gọi trực tiếp trong dịch vụ của tôi.