Unity 入門 (8) - 延遲解析

緒上篇,這次的主題是延遲解析。

本文大綱:
  • 小引
  • 使用 Lazy<T>
  • 使用自動工廠
  • 注入自訂工廠

小引

當我們說「解析某個型別/元件」時,意思通常是呼叫某類別的建構函式,以建立其執行個體(instance)。但有些場合,我們會希望解析時先不要生成物件,而是等到真正要呼叫物件的方法時才建立物件。這種延後建立物件的解析方式,叫做「延遲解析」(deferred resolution)。

延遲解析通常用在哪裡呢?一個典型的場合是欲解析的物件的創建過程需要花較多時間(例如解析時可能因為建構函式需要注入其他物件,而產生多層巢狀解析的情形),而我們希望能加快這個過程,以提升應用程式的回應速度。

本節提供兩種實現延遲解析的作法,一種是 Lazy<T>,另一種是「自動工廠」(automatic factories)。以下兩個小節將分別介紹這兩種作法。

註:本文使用的 IMessageService 相關類別的程式碼在另一篇筆記:Unity 入門 (6) - 自動註冊

使用 Lazy<T>

Unity 可以讓我們直接使用 .NET Framework 內建的 Lazy<T> 來實現延遲解析。試比較底下兩個範例,首先是一般的寫法:

    // 一般寫法
    var container = new UnityContainer();
    container.RegisterType<IMessageService, EmailService>();  // 註冊
   
    var svc = container.Resolve<IMessageService>(); // 解析元件(呼叫實作類別的建構函式)
    svc.SendMessage("Michael", "Hello!");           // 使用元件

然後是 Lazy<T> 的延遲解析寫法,由於註冊型別的程式碼不變,故只列出解析的部分:

    var lazyObj = container.Resolve<Lazy<IMessageService>>(); // 延遲解析
    var svc = lazyObj.Value;                                  // 此時才真正呼叫類別的建構函式
    svc.SendMessage("Michael", "Hello!");                     // 使用元件

註:有關 Lazy<T> 的用法,請參閱 MSDN 線上文件,或搜尋關鍵字「Lazy of T」。
使用自動工廠

「自動工廠」(automatic factories)指的是 DI 容器能夠自動生成一個輕量級的工廠類別,這樣我們就不用花工夫自己寫了。那麼,什麼情況會用到自動工廠呢?通常是用來實現「延遲解析」,或者應付更複雜、更動態的晚期繫結(late binding)的需求。

仍舊以先前提過的 NotificationManager 和 IMessageService 為例。假設 EmailService 這個元件在建立執行個體時需要花費較長的時間(約五秒),參考以下程式片段:

    public class EmailService : IMessageService
    {
        public EmailService()
        {
            // 以暫停執行緒的方式來模擬物件生成的過程需要花費較長時間。
            System.Threading.Thread.Sleep(5000);
        }

        // 其餘程式碼在這裡並不重要,予以省略。
    }

如果照一般的元件解析方式,會這麼寫:

    // (1) 註冊
    var container = new UnityContainer();
    container.RegisterType<IMessageService, EmailService>();            

    // (2) 解析
    var notySvc = container.Resolve<NotificationManager>();
    
    // (3) 呼叫
    notySvc.Notify("Michael", "自動工廠範例");

這種寫法,在其中的「(2) 解析」這個步驟會發生下列動作:

  1. DI 容器欲解析 NotificationManager,發現其建構函式需要傳入 IMessageService 物件,於是先解析 IMessageService。 
  2. 由於先前向容器註冊元件時已經指定由 EmailService 來作為 IMessageService 的實作類別,故容器會先建立一個 EmailService 物件,然後將此物件傳入 NotificationManager 的建構函式,以便建立一個 NotificationManager 物件。

也就是說,在解析 NotificationManager 時便一併建立了 EmailService 物件,故此步驟至少要花五秒的時間才能完成。然而,現在我們想要延後相依物件的創建時機,亦即等到真正呼叫元件的方法時,才真正建立其相依物件的執行個體。像這種場合,我們可以利用 Func<T> 與 Unity 的「自動工廠」來達到延遲解析相依物件的效果。作法很簡單,只要修改 NotificationManager 類別就行了。如下所示:

    class NotificationManager 
    {
        private IMessageService _msgService; 
        private Func<IMessageService> _msgServiceFactory

        public NotificationManager(Func<IMessageService> svcFactory) 
        {
            // 把工廠方法保存在委派物件裡
            _msgServiceFactory = svcFactory;
        }
 
        public void Notify(string to, string msg) 
        {
            // 由於每次呼叫 _msgServiceFactory() 時都會建立一個新的 IMessageService 物件,
            // 這裡用一個私有成員變數來保存先前建立的物件,以免不斷建立新的執行個體。
            // 當然這並非必要;有些場合,你可能會想要每次都建立新的相依物件。
            if (_msgService == null)
            {
                _msgService = _msgServiceFactory(); 
            }

            _msgService.SendMessage(to, msg);
        }
    }

另一方面,原先的「註冊、解析、呼叫」三步驟的程式碼都不用任何改變。方便閱讀起見,這裡再將註冊元件的程式碼貼上來:

    // (1) 註冊
    var container = new UnityContainer();
    container.RegisterType<IMessageService, EmailService>();

請注意,NotificationManager 的建構函式要求注入的明明是 Func<IMessageService>,可是向容器註冊元件時,卻依舊寫 IMessageService,而不用改成 Func<IMessageService>(要五毛,給一塊)。如此一來,當你想要為既有程式碼加入延遲解析(延遲建立相依物件)的能力時,就可以少改一些程式碼。這是 Unity 容器的「自動工廠」提供的好處。

進一步解釋,當 Unity 容器欲解析 NotificationManager 時,發現其建構函式需要一個 Func<IMessageService> 委派(delegate),於是便自動幫你生成這個物件,並將它注入至 NotificationManager 類別的建構函式。由於注入的是委派物件(你可以把它當作是個**工廠方法**),故此時並沒有真正建立 IMessageService 物件,而是等到上層模組呼叫此元件的 Notify 方法時,才透過呼叫委派方法來建立 IMessageService 物件 。

當然,Unity 容器的「自動工廠」可能無法滿足某些需求。比如說,有些相依物件的創建邏輯比較複雜,需要你撰寫自訂的物件工廠。這個時候,你可能會想要知道如何注入自訂工廠。

注入自訂工廠

當你想要讓 Unity 容器在解析特定元件時使用你的自訂工廠來建立所需之相依物件,Unity 框架的 InjectionFactory 類別可以派上用場。
延續上一個小節的 NotificationManager 範例。現在假設你寫了一個物件工廠來封裝 IMessageService 的創建邏輯,像這樣:

    class MessageServiceFactory
    {
        public IMessageService GetService()
        {
            bool isEmail = CheckIfEmailIsUsed();
            if (isEmail)
            {
                return new EmailService();
            }
            else
            {
                return new SmsService();
            }
        }
    }

此物件工廠的 GetService 方法會根據執行時期的某些變數來決定要返回 EmailService 還是 SmsService 的執行個體。EmailService 與 SmsService 這兩個類別都實作了 IMessageService 介面,它們的程式碼在這裡並不重要,故未列出。如需查看這些類別的程式碼,可參閱稍早的〈共用的範例程式〉一節的內容。

NotificationManager 的建構函式與上一節的範例相同,仍舊是注入 Func<IMessageService>。如下所示:

    class NotificationManager 
    {
        private IMessageService _msgService; 
        private Func<IMessageService> _msgServiceFactory

        public NotificationManager(Func<IMessageService> svcFactory) 
        {
            // 把工廠方法保存在委派物件裡
            _msgServiceFactory = svcFactory;
        }
   
        // (已省略其他不重要的程式碼)
    }

剩下的工作,就是告訴 Unity 容器:「在需要解析 IMessageService 的時候,請使用我的 MessageServiceFactory 來建立物件。」參考以下程式片段:

    var container = new UnityContainer();

    // 註冊
    Func<IMessageService> factoryMethod = new MessageServiceFactory().GetService;
    container.RegisterType<IMessageService>(new InjectionFactory(c => factoryMethod()));

    // 解析
    container.Resolve<NotificationManager>();

註冊元件的部分需要加以說明,如下:

  • 先建立一個 Func<IMessageService> 的委派物件,讓它指向 MessageServiceFactory 物件的 GetService 方法。 
  • 接著呼叫 Unity 容器的 RegisterType 方法,告訴容器:解析 IMessageService 時,請用我提供的自訂工廠的 GetService 方法,而這個工廠方法已經包在剛才建立的委派物件(變數 factoryMethod),並透過 Unity 的 InjectionFactory 將此工廠方法再包一層,以便保存於 Unity 容器。

此範例所使用的 RegisterType 是個擴充方法,其原型宣告如下:

    public static IUnityContainer RegisterType<T>(this IUnityContainer container, 
                                                  params InjectionMember[] injectionMembers); 

InjectionFactory 類別繼承自 InjectionMember,而此範例所使用的建構函式之原型宣告為:
    public InjectionFactory(Func<IUnityContainer, object> factoryFunc);

註:如需 InjectionFactory 類別的詳細說明,可參考線上文件

摘自:《 .NET 相依性注入》第 7 章。
Copyright © 2012. Huan-Lin 學習筆記 - All Rights Reserved
Powered by Blogger
Template Design by Cool Blogger Tutorials
Published by Templates Doctor