LLBLGen和存儲庫模式

我想知道是否在頂層LLBLGen（適配器）上構建存儲庫是個不錯的主意。我不想過度開發並重新發明輪子。 DataAccessAdapter類可以是某種通用的存儲庫。它具有您需要的所有CRUD方法。LLBLGen和存儲庫模式

但是對於大型項目的另一方面，在您的ORM和服務層之間建立一個層可能會很好。

我想聽聽你的意見，如果你使用LLBLGen的存儲庫模式，如果是的話，爲什麼如果沒有爲什麼不。

如果你有一些實現，請發佈它。

2010-12-22 user137348

我們使用LLBLGen的存儲庫，但使用自助服務。我們使用存儲庫模式來緩解我們的單元測試。對於簡單的插入/更新，存儲庫只是簡單地調用傳入實體的保存方法。我們最終瞄準的是在存儲庫和業務邏輯之間來回傳遞域對象（不是LLBLGEN實體），並且只在實現的存儲庫中具有ORM（LLBLEN，LINQ-to-SQL等）依賴項。

來源

2010-12-22 16:42:52

有趣。你的domian對象是獨立的對象以吸引人？我想你必須在它們之間做一些映射。 – user137348 2010-12-23 23:48:46

還沒有，但最終。通過獨立的域對象，您可以輕鬆地將您的數據實現從llblgen切換到其他（Linq to SQL，XML等），而不需要任何其他東西（Bll層等）。 – 2010-12-24 14:31:17

直接的好處是可以防止鎖定到特定的技術，使您能夠靈活地選擇適當的技術。

恕我直言，更重要的原因是執行Ubiquitous Language。隨着應用程序/系統的發展，您需要以多種方式查詢數據。 Repository可以幫助您封裝複雜的查詢。

有了一個通用的實現，你的消費者的代碼可能是這樣的：

customerRepo = ServiceLocator.Current.Resolve<IRepository<Customer>>(); 
var matchingCustomers = customerRepo.GetAll().Where(c => <some complex condition here>);

使用存儲庫，它應該是這樣的：

customerRepo = ServiceLocator.Current.Resolve<ICustomerRepository>(); 
var matchingCustomers = myRepo.GetCustomersWithOrdersPendingFor(new DateTime(2010, 12, 31)); 
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

第二個例子顯式聲明的意圖查詢，使得將來更容易/更快地識別。

但是（只是爲了使問題複雜化），您可以使用查詢規範來隔離複雜的查詢邏輯，然後使用通用存儲庫來完成工作。請參閱this post以瞭解它是如何完成的。

我通常做到以下幾點：

創建一個通用的存儲庫（即IRepository <TAggregateRoot>）
每個骨料根目錄下創建信息庫，實現IRepository <TAggregateRoot>
添加根據需要將查詢方法提供給相應的存儲庫
當倉庫變得過於臃腫，重構查詢到單獨的查詢規範

最後請注意：我曾經設計了兩個上線和離線模式下工作的應用程序。最簡單的解決方案是實現兩個具體的存儲庫（使用通用接口），並在客戶端連接/斷開時切換（另一個切換持久性技術的示例）。

來源

2010-12-30 10:17:02

LLBLGen和存儲庫模式

回答

相關問題