Seedstack 中的 Repository 和 Finder 有什么區別？

Question

我正在使用 Seedstack 16.7 及其帶有 JPA 插件支持的業務框架。

有兩種方法可以從數據源獲取數據。

1. 存儲庫http://seedstack.org/docs/business/manual/repositories/

   • 它們幾乎是代表 JPA 上傳統 EntityManager 的那些，保持類型安全。

2. 查找器http://seedstack.org/docs/business/manual/finders/

   • 他們從數據源中檢索 Dto。

它們之間唯一明顯的區別是 finder 是數據源的只讀接口。

finder 所需的大多數查詢都可以通過調用存儲庫並將聚合轉換為 Dto 來完成

它們之間有什么真正的區別，或者它們的意圖嗎？ 除了在這個問題上說的。

Answer 1

用幾行來解釋它有點復雜，因為建模決策來自對 DDD、CQ(R)S、快速讀取模型、最終一致性等的深入理解。

• 發現者

正如手冊所說：“查詢持久層或任何數據源以獲取特定於應用程序接口的對象”。 這里的關鍵字是Interface 。 在圖形 UI 的情況下，查找器的用途是檢索具體視圖以將其呈現在桌面形式或網頁中。 在非 CRUD 應用程序中，UI 應該是基於任務的，因此：

1. 您的觀點與您的實體和聚合不匹配。
2. 您的實體和聚合不（不應該）包含選擇數據的完整列表，即：州和城市（經典的級聯依賴組合框）
3. 你的聚合和實體不（不應該）包含引用實體的完整列表（一個帶有大量訂單列表的客戶類，所有訂單數據，放在里面是錯誤的 DDD 聚合建模）但是你必須在你的應用程序中的某個地方顯示完整的訂單清單。
4. 可以從不同的數據源檢索您的視圖和聚合（通常用於查詢性能和/或最終一致性）。 即 NoSql readmodels，一個非規范化的關系數據庫或域關系數據庫中的預計算視圖（而不是代表您的實體的表）。

因此，您在 UI 和聚合/實體之間存在阻抗失配。 解決此問題的最佳方法是明確地創建一種處理從持久性到視圖的方法。 發現者開始發揮作用。

• 倉庫

當用戶發出一個暗示您的域發生變化的命令時，您必須檢索一個聚合並使用聚合根作為操作的入口點。 這確保了域的一致性和不變性（規則）。 聚合建模有很多細微差別（請看這里），因此嘗試將聚合和實體用於您的視圖是個壞主意。 因此，您需要一種從數據源讀取和構建內存聚合的方法。 這是存儲庫的工作。 有時，存儲庫會為您提供在檢索視圖數據時不需要的額外功能，例如實體更改跟蹤、創建要持久化的唯一標識等。處理視圖時您不需要任何這些功能。 存儲庫開始發揮作用。