AbpModule

     在ABP框架中,倉儲,服務,這塊算是最為重要一塊之一了.ABP框架提供了建立和組裝模組的基礎，一個模組能夠依賴於另一個模組,一個程式集可看成一個模組,

一個模組可以通過一個類來定義這個模組，而給定義這個類要繼承自已經瘋轉好的AbpModule..net通過反射來獲取這些程式集中的類或者方法

模組的呼叫往往涉及到先後順序,如果模組A依賴於模組B,那麼模組B要在模組A之前初始化,初始化就相當於註冊,如使用IocManager對登記類進行註冊,

    上面這個方法我們就把MyModule1 注入到MyModule2中了,在呼叫MyModule2的時候可以初始化MyModule1 .

     什麼是依賴注入呢?百科是這樣說:“依賴注入是一種軟體設計模式，一個或多個依賴項（或服務）被注入或通過引用傳遞到一個依賴物件，並且成為客戶端狀態的一部分。這種模式把客戶端依賴項的建立從它自己的行為中分離出來，允許程式設計成鬆耦合的，遵循依賴倒置和單一職責的原則。和服務定位器模式相比，它允許客戶端知道他們使用的系統查詢依賴項。”

     不使用依賴注入技術，很難管理依賴項和釋出一個結構良好的應用。

倉儲（repository）

     假設我們有一個應用程式服務，使用倉儲（repository）類插入實體到資料庫。在這種情況下，應用程式服務類依賴於倉儲（repository）類,如下

   UserService使用UserRepository插入Person到資料庫。但是這段程式碼有一些問題:

1,服務層UserService通過介面IUserRepository呼叫CreatePerson實現新增一個User物件,看似呼叫了IUserRepository介面,但是實際上還是依賴於倉促層的UserRepository.

2,UserService通過IUserRepository建立物件的時候,實際上new一個UserRepository區實現,這與直接呼叫UserRepository無差別,IUserRepository失去存在的意義.

3,如果未來我們需要修改UserRepository類,但是UserService依賴於它,這時候,我們需要修改所有依賴UserRepository的類.

4,有了這樣的依賴，很難對UserService進行單元測試。

5,與"高內聚低耦合"的的原則背道而馳,這裡可以看到服務層與倉儲層有依賴.

 為了解決這些問題於是就有了下面這個版本.

        這就是工廠模式,實際上在abp之前我也經常用這種方式,非常繁瑣,搭框架老是出錯,UserRepositoryFactory是一個靜態類,建立並返回一個IUserRepository

UserService服務不需要直接去建立UserRepository.

        這種方法雖然可以,但是依然存在一些問題.

1,UserService依然依賴於UserRepositoryFactory

2,每一個倉儲都有寫一個工廠,很繁瑣.

3,測試性還是不好.

依賴注入

解決辦法有幾種,包括屬性注入,建構函式注入,和依賴注入框架等等.

 上面就是abp中建構函式注入與屬性輸入的完美運用.現在，UserService不知道哪些類實現userRepository以及如何建立它。誰需要使用UserService，首先建立一個IUserServiceUserService並將其傳遞給建構函式就可以了.

      有人可能說userRepository的從屬類裡面可能存在依賴,依賴注入框架自動化管理依賴關係都已經解決了這些問題.建構函式注入模式是一個完美的提供類的依賴關係的方式。通過這種方式，你不能建立類的例項，而不提供依賴項。它也是一個強大的方式顯式地宣告是什麼類的需求正確地工作。

       但是，在某些情況下，該類依賴於另一個類，但也可以沒有它。這通常是適用於橫切關注點(如日誌記錄)。一個類可以沒有工作日誌，但它可以寫日誌如果你提供一個日誌物件。在這種情況下，您可以定義依賴為公共屬性，而不是讓他們放在建構函式,上面例子中NullLogger.Instance 是一個單例物件，實現了ILogger介面，但實際上什麼都沒做(不寫日誌。它實現了ILogger例項，且方法體為空),在我們需要寫日誌的地方,我們只需要UserService.Logger = new Log4NetLogger();如此,我們就可以寫入日誌了,如果不寫就不呼叫,因此是一個可選的依賴.

        幾乎所有的依賴注入框架都支援屬性注入模式

        ABP的依賴注入基於 Castle Windsor框架。Castle Windsor最成熟的DI框架之一。依賴注入的框架還有好多，如Unity，Ninject，StructureMap，Autofac等,之前我用過Unity其他的幾個沒有研究過,依賴框架都可以自動解決依賴關係。他們可以建立所有依賴項(遞迴地依賴和依賴關係)。所以你只需要根據注入模式寫類和類建構函式&屬性，其他的交給DI框架處理！在良好的應用程式中，類甚至獨立於DI框架。整個應用程式只會有幾行程式碼或類，顯示的與DI框架互動。

        有人說上面這個例子看不出來依賴注入啊,其實這裡UserService是繼承自IUserService,而IUserService繼承自IApplicationService,abp在IApplicationService封裝了很多東西,ABP會自動註冊它，因為它實現IApplicationService介面(它只是一個空的介面)。它會被註冊為transient (每次使用都建立例項)。當你注入(使用建構函式注入)IUserService介面成一個類，UserService物件會被自動建立並傳遞給建構函式。

        命名約定在這裡非常重要。例如你可以將名字PersonAppService改為 MyPersonAppService或另一個包含“PersonAppService”字尾的名稱，由於IPersonAppService包含這個字尾。但是你可以不遵循PeopleService命名您的服務類。如果你這樣做，它將不會為IPersonAppService自動註冊(它需要自注冊（self-registration）到DI框架，而不是介面)，所以，如果你想要你應該手動註冊它.

上一章我們已經定義實體類,和DTOs,在倉儲中可以直接呼叫,倉儲是在領域層和資料對映層的中介,使用類似集合的介面來存取領域物件.

      介面:

 實現:

   在例子中IRepository繼承自abp已經封裝好的IRepository<TEntity>中,在IRepository<TEntity>中已經為我們封裝好了許多方法,這就省得我們在為每一個倉儲建立不同的方法了,這點很好如下圖.

    包含了各式各樣的方法,如增刪查改等方法.還有一些Async的非同步方法.GetAll返回IQueryable<T>型別的物件。因此我們可以在呼叫完這個方法之後進行Linq操作.

現在專案中運用的是EF框架,所以如果ORM框架沒有提供Async的倉儲方法則它會以同步的方式操作。同樣地,舉例來說,InsertAsync操作起來和EF的新增是一樣的,因為EF會直到單元作業(unit of work)完成之後才會寫入新實體到資料庫中(DbContext.SaveChanges)。

     資料庫連線的開啟和關閉，在倉儲方法中,ABP會自動化的進行連線管理.當倉儲方法被呼叫後,資料庫連線會自動開啟且啟動事務。當倉儲方法執行結束並且返回以後,所有的實體變化都會被儲存, 事務被提交併且資料庫連線被關閉,一切都由ABP自動化的控制。如果倉儲方法丟擲任何型別的異常,事務會自動地回滾並且資料連線會被關閉。上述所有操作在實現了IRepository介面的倉儲類所有公開的方法中都可以被呼叫。如果倉儲方法呼叫其它倉儲方法(即便是不同倉儲的方法),它們共享同一個連線和事務。連線會由倉儲方法呼叫鏈最上層的那個倉儲方法所管理。

      另外所有的倉儲物件都是暫時性的。這就是說,它們是在有需要的時候才會被建立。ABP大量的使用依賴注入，當倉儲類需要被注入的時候,新的類實體會由注入容器會自動地建立.