C#進階系列——MEF實作設計上的“松耦合”（二）

前言：前篇 C#進階系列——MEF實作設計上的“松耦合”（一） 介紹了下MEF的基礎用法，讓我們對MEF有了一個抽象的認識。當然MEF的用法可能不限于此，比如MEF的目錄服務、目錄篩選、重組部件等進階應用在這裡就不做過多講解，因為部落客覺得這些用法隻有在某些特定的環境下面才會用到，着實不太普遍，感覺沒有鑽下去的必要。如果你有興趣也可以去了解下。這篇打算将MEF和倉儲模式結合起來談談MEF在項目中的使用。

1、倉儲模式：也叫Repository模式。Repository是一個獨立的層，介于領域層與資料映射層（資料通路層）之間。它的存在讓領域層感覺不到資料通路層的存在，它提供一個類似集合的接口提供給領域層進行領域對象的通路。Repository是倉庫管理者，領域層需要什麼東西隻需告訴倉庫管理者，由倉庫管理者把東西拿給它，并不需要知道東西實際放在哪。Repository模式一般是用來封裝資料通路層的，這也就是為什麼很多地方看到說的什麼“資料倉儲”，大概就是這個意思。Repository模式并不是本文的重點，這裡就不再展開，後面會單獨分享這塊。

關于倉儲模式有以下幾點需要注意：

（1）Repository模式是架構模式，在設計架構時，才有參考價值；

（2）Repository模式使用的意義：一是隔離業務邏輯層和底層資料通路層，保證資料出入口的唯一性；二是Repository模式針對聚合根設計的，而并不是針對表和實體設計的，換句話說，使用Repository是為了實作内聚，前端隻負責向Repository請求資料即可，而不用關心資料的具體來源；

（3）Repository模式實際用途：更換、更新ORM引擎，不影響業務邏輯；

上面這些東西寫得有點官方。部落客的了解是，倉儲模式就是對資料通路層（或者叫資料映射層）做了一層包裝，每一次前端需要查詢什麼資料或者送出什麼資料的時候，都是通過倉儲對象Repository去操作的，前端基本上感覺不到資料通路層的存在。這樣說你有沒有好了解一點呢？沒有？好吧，我們來看Demo。

2、MEF在倉儲模式上面的應用：由于架構使用的是EF，是以這裡也用EF結合倉儲模式進行講解。為了省略Repository模式的複雜結構，我們僅僅通過倉儲的Save方法來說明。

IRepository<TEntity>接口以及實作代碼：

BaseEntity是一個EF實體的公共基類，定義EF實體必須要遵循的限制。

IUnitOfWork工作單元接口以及實作

既然這裡使用了ImportMany，那麼肯定有一個地方需要Export。我們使用EF建立一個edmx檔案，在生成的上下文對象上面加上Export

這裡為什麼要使用ImportMany？前面說了，倉儲的好處之一在于對資料通路層做封裝，使得前端不比關心資料的具體來源。當我們再建一個資料庫連接配接的edmx時，我們隻需要修改倉儲裡面的Cur_context 這個對象的指派即可，由于其他地方都是針對Cur_context這一個上下文對象做的操作，是以基本都不需要做很大的變化。繞了這麼大一圈，其實部落客隻是想說明Import和ImportMany和倉儲模式結合使用的好處，至于倉儲模式的适用性問題不是本文的重點。