C#進階系列——DDD領域驅動設計初探（三）：倉儲Repository（下）

前言：上篇介紹了下倉儲的代碼架構示例以及簡單分析了倉儲了使用優勢。本章還是繼續來完善下倉儲的設計。上章說了，倉儲的最主要作用的分離領域層和具體的技術架構，使得領域層更加專注領域邏輯。那麼涉及到具體的實作的時候我們應該怎麼做呢，本章就來說說倉儲裡面具體細節友善的知識。

DDD領域驅動設計初探系列文章：

C#進階系列——DDD領域驅動設計初探（一）：聚合

C#進階系列——DDD領域驅動設計初探（二）：倉儲Repository（上）

C#進階系列——DDD領域驅動設計初探（三）：倉儲Repository（下）

C#進階系列——DDD領域驅動設計初探（四）：WCF搭建

C#進階系列——DDD領域驅動設計初探（五）：AutoMapper使用

C#進階系列——DDD領域驅動設計初探（六）：領域服務

C#進階系列——DDD領域驅動設計初探（七）：Web層的搭建

倉儲接口：

倉儲的實作

增加這兩個方法之後，對于單表的一般查詢都可以直接通過lamada表示式的方法傳入即可，并且傳回值為IQueryable類型。

在菜單的倉儲接口裡面：

對應倉儲實作：

 這裡也是傳回的IQueryable接口的集合，千萬不要小看IQueryable接口，它是一種表達式樹，可以延遲查詢。也就是說，在我們執行GetMenusByRole()之後，得到的是一個帶有查詢sql語句的表達式樹結構，并沒有去資料庫執行查詢，隻有在我們ToList()的時候才會去查詢資料庫。我們來寫個Demo測試下。

來看執行過程：

 當程式執行var lstMenu = oProgram.menuRepository.GetMenusByRole(new TB_ROLE() { ROLE_ID = "aaaa" })這一步的時候基本是不耗時的，因為這一步僅僅是在構造表達式樹，隻有在.ToList()的時候才會有查詢等待。更多詳細可以看看此文 Repository 傳回 IQueryable？還是 IEnumerable？。

在dax.net的系列文章中，提到了規約模式的概念，用于解決條件查詢的問題。部落客感覺這個東西設計确實牛叉，但實用性不太強，一般中小型的項目也用不上。有興趣可以看看規約（Specification）模式。