前言:這一個問題之前工作上和組內夥伴有套論過，有了 Entity Framework 那是否還需要用 Repository Pattern?
一、網上反對方，反對EF+Repository
其實也有相關文章說明有了EF 就不需要在寫Repository Pattern，如這篇:
博客园的大牛们，被你们害惨了，Entity Framework从来都不需要去写Repository设计模式
此篇作者反對使用EF 還用Repository Pattern 的前提想法是
EF本身就是repository设计模式的
所以既然EF 本身就是 Repository Pattern，你為何要在包一層 Repository 呢?
並指出EF + Repository 的三大缺點
- 程式太醜(你需要多寫Repository去包)
- 難用(每個實體寫在不同 Repository，但有跨表的操作將會非常難操作)
- 有Bug(作者的論點不是很清楚，是指架構會讓人不小心寫出bug的程式)
二、網上同意方，認為Repository 還是有存在必要
如這篇:
[.NET][Design Patterns] 無辜的 Repository Pattern
此篇作者認為，還是有其必要
Repository 其實是存取資料的抽象化 API，只要是向資料儲存體放資料或要資料的功能，都會經由它來處理，有了抽象化的 API 後，上層的服務 (Service) 只要關心 Repository 的抽象化 API。作者認為，若是一個不需要抽會資料儲存體的應用程式，確實可以不實作Repository，但若有一天老闆發瘋要你換資料庫，那你就必須重寫了，作者最後的註解我也覺得寫得很棒很有道理
當在業界久了，經歷了一些事情，或許你就會了解有時候隨手做的一些動作，有一天會為你省下不少時間，而沒做的話會讓你多了一堆工作。與這篇文章
Dependency inversion vs repository pattern (app layer dependency on ORM)
There is nothing about the repository pattern and dependency injection that is mutually exclusive.
存儲庫模式和依賴注入/服務模式沒有任何互斥的地方。The primary purpose of the Repository Pattern (example) is to divorce your application logic from having to know anything about how to access the data
倉庫模式的主要目的是將應用程序邏輯與了解如何訪問數據分離開來。
三、我的想法
最終，我的想法還是趨近於後者，就是Repository 還是有存在必要，
即使EF 也能夠輕易幫我們完成資料庫類型的抽換，但我認為Repository 最核心的幫助就是讓我們將業務核心與資料存取核心進行隔離，即使使用模式會讓程式碼變得更多，但也多了可讀性、可擴充與可維護性，我認為有以下好處
- 符合符合SOLID的 Dependency inversion principle
高階模組不高依賴低階模組，兩者都該依賴於抽象；業務核心模組不該直接使用資料存取模組，應該利用Repository 當作介面隔離。 - 統一存取介面，有利於擴充與維護
若不使用Repository，操作資料庫的方法將會散在業務層各處，若要統一在讀寫前加個方法，或記Log將會非常麻煩且不好維護 - 替換資料庫僅更動Repository，就能進行
若有理解錯誤可以通知我喔，今天先這樣
