Framework.EF
首先看一下這個類庫：
Extended文件夾存放的是EntityFramework.Extensions這個插件的源代碼，沒有別的原因，就是本人覺得這個插件挺好的，每次省的下載而已
IDependency：用於依賴注入的接口
IRepository和Repository：用於倉儲模式
IUnitOfWork和UnitOfWork：用於單元工作模式
Page：分頁實體
1、什么是依賴注入？
記得第一次接觸依賴注入的時候是在我大二暑假自己出去實習的時候，當時帶我的人讓我看一看依賴注入這個東西，因為項目用到了，我愣是看了一個星期，各種熬夜、百度、問人，還沒明白怎么回事？現在想想挺搞笑的。其實這個東西需要一定的項目經驗理解起來會方便些，其實我們平時在研究問題的時候，當你實在解決不了的時候，不妨先記下來，有空的時候多看看，總有一天會豁然開朗的。扯遠了。。。
其實依賴注入我跟喜歡把它當成控制反轉，這樣更貼切，為什么呢？舉個例子：三層架構中的BLL層，我們通常定義一個接口層讓它繼承，在使用的時候，直接 接口申明 - BLL實例化，而控制反轉的思想是將它們的順序顛倒過來，也就是說我們不再關注接口到底是怎么實現的了，這樣就實現了解耦合，在我看來這是一項偉大的創新。而實現控制反轉這個思想當然是依賴注入容器，當然插件有很多，我用過Unity和Autofac，個人感覺還是第三方的Autofac強大，性能相對於Unity而言十分的明顯
2、什么是倉儲模式？
關於這方面的介紹有很多，我說說我的理解，通常我們所用的ORM都會自己有一套CURD相關的方法，比方說EF中的dbcontext，NH中的session，其實我們會發現在倉儲模式中又會定義一套CURD相關的方法，有的人會問：這TM的不是重復了嗎？當時我也是這么想的，其實不然，如果你的ORM永遠不可能變的話，那么你可以不用倉儲模式，但是這種情況概率基本不可能發生，誰也無法保證你的領導腦袋會不會抽風，萬一，就萬一哪天需要更換底層的東西的呢？如果你使用了倉儲模式的話，這樣更換底層就十分的方便，只需要將倉儲中的實現挨個重寫一遍，這就是好處。
3、什么是單元工作模式？
其實就是統一資源，減少資源浪費而已，我們就拿EF來說，其實我發現有些人會在單元工作模式中定義了一些事務的操作方法，在我看來這是沒有必要的，為什么呢？因為EF中的上下文本身就是具有事務性質的，我們只需要在單元工作模式中定義一個統一提交的方法即可。
本系列完成之后附上源代碼