這篇距離上一篇 Unity 筆記,竟然已經兩年了...Orz
本文內容摘自《.NET 相依性注入》,主角是 Unity 的自動註冊(auto-registraction)功能。
共用的範例程式
為了避免往後重複太多相同的程式碼,這裡先列出共用的介面與類別。
假設情境
假設應用程式需要提供訊息通知機制,而此機制需支援多種發送管道,例如:電子郵件、
簡訊服務(Short Message Service)、行動應用程式的訊息推送(push notification)等等。簡單
起見,這裡僅實作其中兩種服務,而且發送訊息的部分都使用簡單的 Console.WriteLine()
來輸出訊息,方便觀察程式的執行結果。
設計
用一個 NotificationManager 類別來作為整個訊息通知功能的管理員。各類訊息通知機制則由以下類別提供:
以上三個類別均實作同一個介面: IMessageService, 而且 NotificationManager 只知道
IMessageService 介面,而不直接依賴具象類別。以下類別圖描繪了它們的關係:
程式碼
訊息通知管理員的相關程式碼:
這裡採用了 Constructor Injection 的注入方式,由建構函式傳入訊息服務。其中的 Notify 方法則利用事先注入的訊息服務來發送訊息給指定的接收對象(引數 ‘to‘)。在真實世界中,你可能會需要用額外的類別來代表訊息接收對象(例如設計一個 MessageRecipient 類 別來封裝收件人的各項資訊),這裡為了示範而對這部分做了相當程度的簡化。
底下是各類訊息服務的程式碼:
自動註冊
「自動註冊」的另一種說法是「依慣例註冊」(registration by convention),主要用意是讓開發人員能夠少寫一些註冊型別的程式碼。Unity 是透過擴充方法 RegisterTypes(注意 “Types” 是複數)來提供自動註冊的功能。此方法有兩個多載版本,底下是它們的原型宣告:
先來看一個簡單的用法,使用的是上列標示(1) 的RegisterTypes 多載方法:
這裡省略了大部分非必要的參數,而只傳入兩個參數:
假設此範例應用程式目前已載入的組件當中已經有一個EmailService 類別,而且該類別實作了IMessageService 介面,那麼當應用程式需要取得符合IMessageService 介面的物件時,由於Unity 已經自動尋找並註冊了相關型別,於是我們便可透過先前提過的型別解析方法來取得物件:
解決重複型別對應的問題
預設情況下,「自動註冊」會採用未具名的「預設註冊」(這名詞前面有提過),而且在碰到欲解析的類別有多載建構函式時,會根據一套既定規則來挑選建構函式。因此,如果只用剛才的簡單範例來進行自動註冊,很可能會在程式執行時發生型別註冊失敗或無法解析 特定型別的錯誤。
就拿前面提過的訊息通知服務的範例來說, 由於 EmailService 和 SmsService 都實作了 IMessageService 介面,若以上述範例程式來進行自動註冊,那麼當程式執行時,將會在呼叫 RegisterTypes 方法的地方發生重複型別對應的錯誤:
碰到這種情形,你可以透過 RegisterTypes 方法的 getName 參數(它是個委派)來為不同的類別提供不同的註冊名稱。
其中的WithName 是Unity 提供的輔助類別,而它的TypeName 方法可傳回指定型別的名稱。也就是說,如果沒有特別複雜的需求,我們可以直接把WithName.TypeName 方法傳遞給getName 參數。如此一來,每一個具象類別的型別對應關係就會以該類別的名稱來命名。於是,在解析物件的時候,也必須明白指定註冊名稱。像這樣:
另一個避免型別對應重複的解決方法,是利用參數overwriteExistingMappings。當你只需要找到任何一個可用的實作類別,而不在乎 Unity 最終會採用哪一個,此時便可將參數 overwriteExistingMappings 指定為 true,如此亦可避免型別對應重複的問題,而且無須使用具名註冊。參考以下範例:
接著要來進一步了解 AllClasses 和WithMappings 類別還提供了哪些輔助功能。(略,請參考本書內容,或查看線上文件:AllClasses,WithMappings)
無恥連結:[書訊]《.NET 相依性注入》
本文內容摘自《.NET 相依性注入》,主角是 Unity 的自動註冊(auto-registraction)功能。
共用的範例程式
為了避免往後重複太多相同的程式碼,這裡先列出共用的介面與類別。
假設情境
假設應用程式需要提供訊息通知機制,而此機制需支援多種發送管道,例如:電子郵件、
簡訊服務(Short Message Service)、行動應用程式的訊息推送(push notification)等等。簡單
起見,這裡僅實作其中兩種服務,而且發送訊息的部分都使用簡單的 Console.WriteLine()
來輸出訊息,方便觀察程式的執行結果。
設計
用一個 NotificationManager 類別來作為整個訊息通知功能的管理員。各類訊息通知機制則由以下類別提供:
- EmailService:透過電子郵件發送訊息
- SmsService:透過簡訊服務發送訊息
以上三個類別均實作同一個介面: IMessageService, 而且 NotificationManager 只知道
IMessageService 介面,而不直接依賴具象類別。以下類別圖描繪了它們的關係:
程式碼
訊息通知管理員的相關程式碼:
這裡採用了 Constructor Injection 的注入方式,由建構函式傳入訊息服務。其中的 Notify 方法則利用事先注入的訊息服務來發送訊息給指定的接收對象(引數 ‘to‘)。在真實世界中,你可能會需要用額外的類別來代表訊息接收對象(例如設計一個 MessageRecipient 類 別來封裝收件人的各項資訊),這裡為了示範而對這部分做了相當程度的簡化。
底下是各類訊息服務的程式碼:
自動註冊
「自動註冊」的另一種說法是「依慣例註冊」(registration by convention),主要用意是讓開發人員能夠少寫一些註冊型別的程式碼。Unity 是透過擴充方法 RegisterTypes(注意 “Types” 是複數)來提供自動註冊的功能。此方法有兩個多載版本,底下是它們的原型宣告:
先來看一個簡單的用法,使用的是上列標示(1) 的RegisterTypes 多載方法:
// 範例:讓Unity 容器自動掃描組件並註冊型別。 var container = new UnityContainer(); container.RegisterTypes( AllClasses.FromLoadedAssemblies(), // 掃描目前已經載入此應用程式的全部組件。 WithMappings.FromAllInterfaces); // 尋找所有介面。
這裡省略了大部分非必要的參數,而只傳入兩個參數:
- 參數 types 是具象類別清單。這裡使用了 Unity 提供的輔助類別 AllClasses 的 FromLoadAssemblies 方法來提供類別清單。
- 參數 getFromTypes 是個用來取得來源型別清單的委派(delegate)。「來源型別」 指的就是註冊型別對應關係時的抽象型別。這裡傳入的委派是指向Unity 的 WithMappings.FromAllInterfaces 方法,作用是取得所有類別所實作的介面。
假設此範例應用程式目前已載入的組件當中已經有一個EmailService 類別,而且該類別實作了IMessageService 介面,那麼當應用程式需要取得符合IMessageService 介面的物件時,由於Unity 已經自動尋找並註冊了相關型別,於是我們便可透過先前提過的型別解析方法來取得物件:
var svc = container.Resolve();
解決重複型別對應的問題
預設情況下,「自動註冊」會採用未具名的「預設註冊」(這名詞前面有提過),而且在碰到欲解析的類別有多載建構函式時,會根據一套既定規則來挑選建構函式。因此,如果只用剛才的簡單範例來進行自動註冊,很可能會在程式執行時發生型別註冊失敗或無法解析 特定型別的錯誤。
就拿前面提過的訊息通知服務的範例來說, 由於 EmailService 和 SmsService 都實作了 IMessageService 介面,若以上述範例程式來進行自動註冊,那麼當程式執行時,將會在呼叫 RegisterTypes 方法的地方發生重複型別對應的錯誤:
An unhandled exception of type ‘Microsoft.Practices.Unity.DuplicateTypeMappingException’ occurred in Microsoft.Practices.Unity.RegistrationByConvention.dll
碰到這種情形,你可以透過 RegisterTypes 方法的 getName 參數(它是個委派)來為不同的類別提供不同的註冊名稱。
var container = new UnityContainer(); container.RegisterTypes( AllClasses.FromLoadedAssemblies(), // 掃描目前已經載入此應用程式的全部組件。 WithMappings.FromAllInterfaces, // 尋找所有介面。 getName: WithName.TypeName); // 使用類別名稱來當作註冊名稱。
其中的WithName 是Unity 提供的輔助類別,而它的TypeName 方法可傳回指定型別的名稱。也就是說,如果沒有特別複雜的需求,我們可以直接把WithName.TypeName 方法傳遞給getName 參數。如此一來,每一個具象類別的型別對應關係就會以該類別的名稱來命名。於是,在解析物件的時候,也必須明白指定註冊名稱。像這樣:
var svc = container.Resolve("EmailService");
另一個避免型別對應重複的解決方法,是利用參數overwriteExistingMappings。當你只需要找到任何一個可用的實作類別,而不在乎 Unity 最終會採用哪一個,此時便可將參數 overwriteExistingMappings 指定為 true,如此亦可避免型別對應重複的問題,而且無須使用具名註冊。參考以下範例:
var container = new UnityContainer(); container.RegisterTypes( AllClasses.FromLoadedAssemblies(), // 掃描目前已經載入此應用程式的全部組件。 WithMappings.FromAllInterfaces, // 尋找所有介面。 overwriteExistingMappings: true); // 有多個符合條件的類別時,採用最後找到的那個。
接著要來進一步了解 AllClasses 和WithMappings 類別還提供了哪些輔助功能。(略,請參考本書內容,或查看線上文件:AllClasses,WithMappings)
無恥連結:[書訊]《.NET 相依性注入》
沒有留言: