本以為,關於這方面的理解,園子中的文章已經很多的了,再多做文章真的就“多做文章了”,但是最近發現,還是有必要的,首先,每個人對於同一事物的理解方式和出發點都是不同的,所以思考的方式得到結果也是不同的。另外鑒於網友 @白細胞 的需求,需要對這方面的理解,索性寫寫,時間有些緊張,所有拖了兩天,抱歉。
首先,在此說明,本人從未有人教過,也沒有在公司的項目中使用過這些內容,原因很簡單,ZF的東西,用不到這些,實屬無奈直覺,而本人卻相當,甚至放盪的喜好這些東西。結束~~~
以下分三點簡要講述:1,repository模式 2,UnitOfWork模式,3,二者常用關系
一,repository模式
描述和作用:
按照最初提出者的介紹,它是銜接數據映射層和域之間的一個紐帶,作用相當於一個在內存中的域對象集合。客戶端對象把查詢的一些實體進行組合,並把它們提交給Repository。對象能夠從Repository中移除或者添加,就好比這些對象在一個Collection對象上就行數據操作,同時映射層的代碼會對應的從數據庫中取出相應的數據。
從概念上講,Repository是把一個數據存儲區的數據給封裝成對象的集合並提供了對這些集合的操作。。。。。。。
在領域驅動設計中,我們有個集合(aggregate)的概念, 通常我們是對於domain的每個集合會對應的定義一個repository。也就說,並不是每個實體都會有對應的一個repository。(假設這是一個倉庫,簡介源自網上摘錄。。)
二,UnitOfWork模式
描述和作用:
簡說了,主要作用是在數據持久化過程中,數據提,確保數據的完整性,對象使用確保同一上下文對象。如果有異常,提供回滾。
三,二者的關系
即:
工作單元服務於倉儲,並在工作單元中初始化上下文,為倉儲單元提供上下文對象,由此確保同一上下文對象。
那么此時,問題來了,怎么在倉儲中獲取上下文。(使用的orm為 EF,以autofac或者MEF實現注入,以此為例) 所以,此時實現就變得很簡單。
看腳本:
UOW中
在uow中初始化上下文對象,定義了Context的屬性對象(當然,這地方可以不初始化,可以有IOC在注入時候帶入參數注入,詳見IOC,常見方式就幾種,實現方式也很類似。) 此處如果看的覺得不爽,換成DbSet對象也可,您請隨意。
repository中
在倉儲構造函數中,默認初始化倉儲對象和獲取上下文對象,好像講完了,沒有了~~~~
以下是本人目前的,我可以說寫着玩的嗎?就是比較喜愛,但是有弊端,用久了就發覺了,二者組合不是很合適,盡管很多人推崇。當然好處顯而易見,就是提供了統一的開發模式和規范,是開發人員的開發方式更具規則性 ,更好維護。
uow:
public OlympicOverDbContext Context {get{......初始化上下文}}
repository倉儲:
....增改刪,略....
如有理解不當之處,還各位大能指出,多多賜教,謝謝。