Repository,我可能不會用你 (3) - 正反意見

這篇筆記整理 Oren Eini 與 Grey Young 兩人在部落格上筆戰 Repository 模式的一些論點。不是很完整,看看就好....

在<Repository,我可能不會用你>文後附的延伸閱讀裡面,有兩篇是出自 Oren Eini 的部落格。Oren Eini 很明顯是反對 Repository 的。他寫了好幾篇文章批評 Repository,甚至拿 CodePlex 上面的程式碼當作例子,清楚表明他對「過度設計」有多麼厭惡。
Oren Eini 何許人也?Rhino Mocks 就是他寫的。他同時也主導或參與  RavenDB、NHibernate、和 Castle 專案的開發,還寫了本書:DSLs in Boo: Domain Specific Languages in .NET

在一篇標題為「Repository is the new Singleton」的文章裡,Oren 提到 Repository 有兩個問題。首先,查詢條件通常很多樣、複雜,結果就是在 Repository 類別裡面加入一堆查詢方法,例如:
  • FindCustomer(id)
  • FindCustomerWithAddresses(id)
  • FindCustomerWith...

Oren 提出的解決辦法是使用查詢物件來封裝查詢條件。這裡的查詢物件,其作用與 query specification 類似,只是實作方法不太一樣。

其次,Oren 認為 Repository 之所以如此普遍,大多是受到 DDD 的影響。他認為 DDD 務須謹慎為之,除非真有需要才用它,否則很可能比不用 DDD 還糟糕。此外,他也認為多數人只是把 Repository 設計成 DAO,而不是 DDD 所說的那種 Repository。

最後,他把自己的資料存取策略歸納成四點:
  • 當資料來源是資料庫時,直接使用 NHibernate 的 ISession。
  • 把複雜的查詢條件封裝成查詢物件。
  • 尊重底層的 storage 實作:如果資料來源不是資料庫,就為它寫一個 DAO。
  • 別保護開發人員。(連結指向另一篇文章,大意是應該讓開發人員成長,而非處處框架限制、保護他們)

老實說,我覺得他的幾篇批 Repository 模式的文章並沒有把他的解決方法解釋得很清楚(內心獨白:show me the code!)。或許就如他在某篇文章裡面說的,他的想法散落在各篇文章裡面,單單一篇文章無法窺得全貌。
2014-05-08 補充:他在一次演講中解釋了他認為好的設計方式:Breaking apart conceptions(可是我真的聽不太懂他的英語,哭!)

筆戰

Oren Eini 對 Repository 的批評自然引來不少質疑,其中有位仁兄就特地寫了篇文章來反駁:Repository is Dead: Long Live Repository。此人是 Greg Young。我對他不太熟悉,只知道他是個獨立顧問,到處演講,以及為《Exploring CQRS and Event Sourcing》一書寫序。

Greg Young 在那篇文章的幾個重點如下:
  • Repository 介面不必是物件導向的;它代表了一個架構邊界,亦即 tier/layer 之間的一個邊界。在定義這樣的邊界時,通常會比較程序導向(我不太確定他的意思,但我猜他指的是接著提到的 CQS 模式)。
  • 沒有將 Repository 視為 tier/layer 邊界的人,是誤用了 Repository 模式。
  • 對於複雜的查詢條件,為了避免寫一堆類似 GetCustomerByID、GetCustomerByXyz123 的方法,建議將「讀」和「寫」的操作分開,也就是使用 CQS(Command and Query Separation)模式。而 Oren 文章提到的解法是查詢物件(query object),根本了無新意。
  • Oren 既然認為「Repository 已死」,卻又在文章裡嘗試提出基於 Repository 的改進方案,簡直矛盾。

Oren 看到那篇打臉文章後,寫了一篇 Night of the living Repositories 作為回應。嗯....有部電影叫作《活死人之夜》,英文片名是 Night of the Living Dead。兩個標題只有一字之差,但 Oren 可沒說 Repositories = Dead 喔。他還挺幽默的 :)

底下是他的反擊內容概要:
  • 我(Oren)壓根沒說過「Reporitory 模式已死」這種話;我只是說,此模式沒有考慮到既有 ORM 框架的優點,以及在 ORM 之上再疊一層 Repository 其實沒有得到多大好處。
  • Greg 說我自相矛盾:既反對 Repository,卻又使用 Repository 模式來解決問題。但我看不出來我原先的文章哪裡有建議使用 Repository。我提出的方法中根本沒有 Repository;資料儲存的部分是直接由 ORM 框架(NHibernate)負責,資料查詢的部分則是利用查詢物件。
  • 邊界之說,我懂。但我不確定這樣的「人工邊界」是否恰當。
  • 就算使用 CQS 模式,我也會需要為資料寫入操作提供不同的提取策略(fetch plan)。我認為提取策略是個重要觀念,原因就在於此。

然後,Greg 的回應:More on Repository
然後,Oren 又回應:The Repository's Daughter。(哈!這是《將軍的女兒》續集嗎?)

筆戰到此大致結束。我沒有全部看完,說實在,挺累的。也許兩人在替自己觀點辯護時,在心中都有個特定的 context,而彼此的 context 不太相同,以至於有時候出現雞同鴨講的情形,繼續爭論下去肯定沒完沒了。

小結

有句話說得好:「讓想結婚的結婚吧,不想結婚的繼續維持單身吧,反正他們終究都會後悔的。」
我依樣畫葫蘆:「想用 Repository 就用,不想用的就別用吧,反正他們終究會把事情做對的。」

結論:Oren 一定也很愛看電影。

Post Comments

技術提供:Blogger.