在MVC中，常常會看到有人把直接在Controller寫資料庫邏輯，造成controller的肥大難以維護，而且這樣也違反了最初MVC要將三塊切開的用意，與SOLID原則中的單一職責原則，而且controller相依於Model導致我們無法對controller做Unit Test。
這時，Repository Pattern就可以派上用場，那Repository其實是一個倉儲的概念，他將原本MVC透過EntityFramework的方式存取DB，再包一層Repository來達到關注點分離。

但是Asp.net mvc專案中有了EntityFramework，在於需不需要用用到Repository的概念還是要依需求來決定，畢竟要在EF上再包一層可能會導致程式碼複雜性增加，卻得不到相對比例的好處，但是練功還是可以試試(?)

互動方式

圖片來源:msdn:https://msdn.microsoft.com/en-us/library/ff649690.aspx

將原本寫在Controller的資料庫邏輯抽出來寫在Repository，並且透過Repository的封裝方式集中管理，資料庫的商業邏輯，這麼一來也可以集中管理，也可以減少在多個Controller中寫相同商業邏輯的method。

Query Object:
常常會發現我們很多controller都會用到重複性的功能，搜尋又可能分很多種情況進行查詢，導致必須重複寫很多個相同功能，用Interface裡面可以用Query去代表想要傳入一個參數，不用指參數一定為某個型別，是一個很方便的方法

Unit of Work:
主要是達成多筆資料的交易或商業邏輯可能很複雜的時候，換句話說，功能可能不只接觸一個Repository的時候，可以將多個邏輯處理好後，使用Commit()動作，一次完成想要的動作

IEnumerable<Product> Find(Query query);
IEnumerable<Product> Find(Query query , int take);

圖片來源:https://www.asp.net/mvc/overview/older-versions/getting-started-with-ef-5-using-mvc-4/implementing-the-repository-and-unit-of-work-patterns-in-an-asp-net-mvc-application

從這張圖更可以看出Repository封裝商業邏輯並被Unit of Work包起來，在單元測試與真實環境就可以很方便的抽換做測試。

文末

Repository一開始的用意，是隔離BLL(商業邏輯層)與DAL(資料存取層)，讓領域邏輯不相依DB。系統演進的過程中就會發現，Repository除了隔離DB、讓BLL層更加的凝聚之外，也封裝的資料來源這個概念。 也就是說系統之外的資料來源，都可以用Repository去隔離。

學習資源

https://www.youtube.com/watch?v=R-x7xr6PHRQ
http://www.wrox.com/WileyCDA/WroxTitle/Professional-ASP-NET-Design-Patterns.productCd-0470292784,descCd-DOWNLOAD.html
http://www.dotnetcurry.com/aspnet-mvc/1155/aspnet-mvc-repository-pattern-perform-database-operations
https://dotblogs.com.tw/clark/2012/04/29/71883
https://www.youtube.com/watch?v=b21ngceixcU
http://huan-lin.blogspot.com/2012/10/designing-layered-application-2.html
http://martinfowler.com/eaaCatalog/repository.html
http://huan-lin.blogspot.com/2012/11/repository-yagni.html