Repository，我可能不會用你 (3) - 正反意見
文章目錄
這篇筆記整理 Oren Eini 與 Grey Young 兩人在部落格上筆戰 Repository 模式的一些論點。不是很完整，看看就好....
在＜Repository，我可能不會用你＞文後附的延伸閱讀裡面，有兩篇是出自 Oren Eini 的部落格。Oren Eini 很明顯是反對 Repository 的。他寫了好幾篇文章批評 Repository，甚至拿 CodePlex 上面的程式碼當作例子，清楚表明他對「過度設計」有多麼厭惡。
在一篇標題為「Repository is the new Singleton」的文章裡，Oren 提到 Repository 有兩個問題。首先，查詢條件通常很多樣、複雜，結果就是在 Repository 類別裡面加入一堆查詢方法，例如：
Oren 提出的解決辦法是使用查詢物件來封裝查詢條件。這裡的查詢物件，其作用與 query specification 類似，只是實作方法不太一樣。
其次，Oren 認為 Repository 之所以如此普遍，大多是受到 DDD 的影響。他認為 DDD 務須謹慎為之，除非真有需要才用它，否則很可能比不用 DDD 還糟糕。此外，他也認為多數人只是把 Repository 設計成 DAO，而不是 DDD 所說的那種 Repository。
最後，他把自己的資料存取策略歸納成四點：
老實說，我覺得他的幾篇批 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 在那篇文章的幾個重點如下：
Oren 看到那篇打臉文章後，寫了一篇 Night of the living Repositories 作為回應。嗯....有部電影叫作《活死人之夜》，英文片名是 Night of the Living Dead。兩個標題只有一字之差，但 Oren 可沒說 Repositories = Dead 喔。他還挺幽默的 :)
底下是他的反擊內容概要：
然後，Greg 的回應：More on Repository。
然後，Oren 又回應：The Repository's Daughter。（哈！這是《將軍的女兒》續集嗎？）
筆戰到此大致結束。我沒有全部看完，說實在，挺累的。也許兩人在替自己觀點辯護時，在心中都有個特定的 context，而彼此的 context 不太相同，以至於有時候出現雞同鴨講的情形，繼續爭論下去肯定沒完沒了。
小結
有句話說得好：「讓想結婚的結婚吧，不想結婚的繼續維持單身吧，反正他們終究都會後悔的。」
我依樣畫葫蘆：「想用 Repository 就用，不想用的就別用吧，反正他們終究會把事情做對的。」
結論：Oren 一定也很愛看電影。
在＜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 看到那篇
底下是他的反擊內容概要：
- 我（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 一定也很愛看電影。