Một kho lưu trữ thực sự nên làm gì?


14

Tôi đã nghe rất nhiều mẫu kho lưu trữ, nhưng tôi hoàn toàn không hiểu kho lưu trữ thực sự nên làm gì. Khi tôi nói "những gì một kho lưu trữ thực sự nên làm" tôi chủ yếu quan tâm đến việc nên cung cấp phương pháp nào. Ví dụ, một kho lưu trữ thực sự cung cấp các phương thức CRUD hay nó nên cung cấp một số loại phương thức khác nhau?

Ý tôi là, các kho lưu trữ có chứa logic nghiệp vụ hay đơn giản là chúng nên chứa logic để giao tiếp với kho lưu trữ dữ liệu và quản lý các thực thể được lưu hoặc tải?

Ngoài ra, tôi đã nghe nói rằng các kho lưu trữ là đơn vị kiên trì cho tổng hợp. Nhưng làm thế nào được? Tôi không hiểu làm thế nào điều này hoạt động trong thực tế. Tôi nghĩ rằng chúng ta chỉ nên có một giao diện IRepositorychứa các phương thức CRUD, và sau đó đối với bất kỳ thực thể nào, việc triển khai sẽ chỉ chứa logic để lưu và truy xuất loại đó từ kho lưu trữ dữ liệu.


4
"Các kho lưu trữ có chứa logic kinh doanh" - không.
ozz

1
Đây là câu trả lời của tôi cho một câu hỏi liên quan trên SO
Eric King

2
Tôi nghĩ rằng bạn đang bị cuốn vào từ "nên" - kho lưu trữ là một mẫu cụ thể, bạn nói như thể có một cách repo nên được thực hiện đó là cách tốt nhất để thực hiện repo; Đây là một quan niệm sai lầm vì có một cách để làm một repo, bất cứ điều gì khác sẽ không phải là một repo. Như vậy mẫu repo có điểm mạnh và điểm yếu, nhưng không có nhiều cách tiếp cận với repo. Có tuy nhiên nhiều cách để tương tác với dữ liệu, trong đó một repo chỉ có một. Đọc ở đây để biết một số cách tiếp cận tương tác dữ liệu khác
Jimmy Hoffa

Câu trả lời:


13

Chà, bạn có thể thấy một ví dụ hay trong Khung dữ liệu mùa xuân dựa trên khái niệm về kho lưu trữ.

Ở đó bạn sẽ thấy các kho lưu trữ chỉ xử lý kho lưu trữ dữ liệu và hiếm khi chứa bất kỳ logic nghiệp vụ nào (phần này được dành riêng cho lớp dịch vụ). Vì vậy, ví dụ, bạn hãy xem thiết kế của họ, bạn sẽ thấy họ có giao diện CRUDRep repository hiển thị các phương thức để tạo, hủy và khôi phục các thực thể (trong số những thứ khác). Ngoài ra còn có PagingAndSortingRep repository bổ sung thêm chức năng cho chính xác đó, sắp xếp và phân trang kết quả, v.v.

Vì vậy, khung này có lẽ là một nơi tốt để nghiên cứu một thiết kế kho lưu trữ tốt.

Theo như tôi biết, nhiều khái niệm được triển khai bởi Spring Data Framework, đến từ một cuốn sách tuyệt vời có tên là Thiết kế hướng tên miền: Xử lý sự phức tạp trong trái tim của phần mềm , cuốn sách có toàn bộ phần dành riêng cho thiết kế Kho lưu trữ.

Bạn có thể xem xét nhận được một bản sao của nó.

Một đoạn trích nhỏ từ cuốn sách giải thích:

Mẫu REPOSITORY là một khung khái niệm đơn giản để gói gọn các giải pháp đó và mang lại trọng tâm mô hình của chúng tôi.

REPOSITORY đại diện cho tất cả các đối tượng thuộc một loại nhất định dưới dạng một tập hợp khái niệm (thường được mô phỏng). Nó hoạt động như một bộ sưu tập, ngoại trừ với khả năng truy vấn phức tạp hơn. Các đối tượng thuộc loại thích hợp được thêm và xóa, và máy móc đằng sau REPOSITORY chèn chúng hoặc xóa chúng khỏi cơ sở dữ liệu. Định nghĩa này tập hợp một tập hợp trách nhiệm gắn kết để cung cấp quyền truy cập vào gốc rễ của AGGREGATE từ vòng đời đầu đến cuối.

Khách hàng yêu cầu các đối tượng từ REPOSITORY bằng các phương thức truy vấn chọn các đối tượng dựa trên các tiêu chí được chỉ định bởi máy khách, thường là giá trị của các thuộc tính nhất định. REPOSITORY truy xuất đối tượng được yêu cầu, đóng gói bộ máy của các truy vấn cơ sở dữ liệu và ánh xạ siêu dữ liệu. REPOSITORIES có thể thực hiện một loạt các truy vấn chọn đối tượng dựa trên bất kỳ tiêu chí nào khách hàng yêu cầu. Họ cũng có thể trả về thông tin tóm tắt, chẳng hạn như đếm có bao nhiêu trường hợp đáp ứng một số tiêu chí. Họ thậm chí có thể trả về các tính toán tóm tắt, chẳng hạn như tổng trên tất cả các đối tượng phù hợp của một số thuộc tính số.

Một REPOSITORY nâng một gánh nặng lớn từ khách hàng, giờ đây có thể nói chuyện với một giao diện đơn giản, tiết lộ ý định và hỏi xem nó cần gì về mô hình. Để hỗ trợ tất cả điều này đòi hỏi rất nhiều cơ sở hạ tầng kỹ thuật phức tạp, nhưng giao diện đơn giản và được kết nối về mặt khái niệm với mô hình miền.

Vì thế:

Đối với mỗi loại đối tượng cần truy cập toàn cầu, hãy tạo một đối tượng có thể cung cấp ảo ảnh về bộ sưu tập trong bộ nhớ của tất cả các đối tượng thuộc loại đó. Thiết lập quyền truy cập thông qua giao diện toàn cầu nổi tiếng.

Cung cấp các phương thức để thêm và xóa các đối tượng, sẽ đóng gói việc chèn hoặc xóa dữ liệu thực tế trong kho lưu trữ dữ liệu. Cung cấp các phương thức chọn đối tượng dựa trên một số tiêu chí và trả về các đối tượng hoặc bộ sưu tập đối tượng được khởi tạo hoàn toàn có giá trị thuộc tính đáp ứng tiêu chí, từ đó gói gọn công nghệ lưu trữ và truy vấn thực tế. Chỉ cung cấp REPOSITORIES cho các gốc AGGREGATE thực sự cần truy cập trực tiếp. Giữ khách hàng tập trung vào mô hình, ủy thác tất cả lưu trữ đối tượng và truy cập vào REPOSITORIES.


4

Nó sẽ không cung cấp giao diện CRUD thẳng cũng như logic kinh doanh. Nó làm trung gian giữa logic kinh doanh và cơ sở dữ liệu. Giao diện nên theo thuật ngữ logic kinh doanh nhưng không thực hiện chính logic kinh doanh, giống như một logic nguyên thủy kinh doanh. Ví dụ, bạn sẽ xây dựng một hệ thống email, bạn có người dùng và tin nhắn. Kho lưu trữ của bạn sẽ cung cấp các thao tác CRUD cơ bản cho người dùng và tin nhắn nhưng nó cũng sẽ cung cấp các chế độ xem tin nhắn được lọc như GetUsersNewMessages (người dùng) hoặc GetSearchedMessages (người dùng, searchTerms).

Ý tưởng là Kho lưu trữ ẩn cách thức lưu trữ được triển khai và cung cấp giao diện sạch cho phép truy cập dữ liệu linh hoạt nhanh chóng. Giữ các hoạt động ở mức độ cao về những gì sẽ xảy ra thay vì làm thế nào có nghĩa là bạn linh hoạt hơn để thực hiện chúng theo bất kỳ cách nào là tốt nhất cho cửa hàng sao lưu cơ bản.

Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.