MVC 儲存庫模式設計決策
我有一個 asp .net MVC 應用程序，最近開始使用服務驗證層實現儲存庫模式，就像這樣。
我一直在為我創建的每個模型創建一個儲存庫/服務。這是矯枉過正嗎？相反，我應該為每個為許多不同模型提供 CRUD 的邏輯業務領域創建一個儲存庫/服務嗎？
對我來說，似乎我要麼用許多文件弄亂了項目樹，要麼用許多方法弄亂了一個類。6 一種方式，另一種方式半打。無論哪種方式，您都能想到任何好的論據嗎？
通常，如果您使用的是“真正的”儲存庫模式，而不是其他持久層（例如 ActiveRecord 或 DAO），您應該旨在辨識您的域聚合，並為每個聚合創建一個儲存庫。
這意味著什麼？好吧，這在很大程度上取決於您的應用程序，但通常有些對象自然是其他對象的“父母”，或者是相關事務的一部分。
我認為典型的例子是一個電子商務系統，其中你有一個訂單的概念，在一個訂單中你有訂單，每個訂單都是一些產品和數量，等等。
在這種情況下，Order 對像是系統的聚合根之一，並且創建了一個 OrderRepository。
在這種情況下要記住的是，訂單與其訂單線等之間存在某種關係（暗示或其他）。因此，儲存庫上“CRUD”的 C-UD 部分通常應該只有一個方法，並且通常應該只接受該聚合根對象的一個實例並對其進行操作（例如 repo.Save(order)）。可能還有其他可能的參數，但這取決於您的 impl。
事實上，您通常可以通過繼承解決大部分 C-UD 部分（即，使用一些已知的邏輯來實現它們的 RepositoryBase，這些邏輯關於您的特定持久性方案應該發生什麼）。
所以這給我們留下了 CRUD 的 R 部分。在這種情況下，如果您選擇使用查詢方法路線，您可能會獲得大量查詢方法（GetById；GetByName；GetByCustomerName 等）。有些人更喜歡，特別是對於簡單的應用程序，公開一個基於 linq 的介面（例如，一個 IQueryable GetAll()），然後可以應用 Where 子句。YMMV 取決於您對該應用的潛在持久性，但對於簡單的應用程序來說，它是一個可靠的選擇，尤其是。如果您希望您的持久性提供程序直接支持 linq。
最後，許多人實際上通過一種或另一種命令查詢職責分離模式的實現來分離查詢部分，該模式表示持久化和查詢的介面應該不同。在這種情況下，您將擁有一個僅具有基本 CRUD（GetById、GetAll、Save、Delete）操作的 Repo 和另一類根據您的應用程序的意圖查詢事物的類。
希望有幫助。
保羅