Inside ObjectBuilder Part 2

摘要:Object Builder Application Block

Object Builder Application Block
 
/黃忠成   
2006/9/21 

 

三、ObjectBuilder Application Block
 
 ObjectBuilder一開始出現於Microsoft所提出的Composite UI Application Block,主司物件的建立及釋放工作,她實現了本文前面所提及的Dependency Injection概念,同時在架構上提供了高度的延展性。運用ObjectBuilder來建立物件,設計師可以透過程式或組態檔,對物件建立與釋放的流程進行細部的調整,例如改變物件建立時所呼叫的Constructor(建構子),調整傳入的參數,於物件建立後呼叫特定函式等等。鑑於ObjectBuilder的功能逐漸完整,加上社群對於Dependency Injection實作體的強烈需求,Microsoft正式將ObjectBuilder納入Enterprise Library 2006中,並修改CachingLoggerSecurityData AccessApplication Block的底層,令其於ObjectBuilder整合,以此增加這些Application Block的延展性。就官方文件的說明,ObjectBuilder Application Block提供以下的功能。
1
l           允許要求一個抽象物件或介面,ObjectBuilder會依據程式或組態檔的設定,傳回一個實體物件。
l           回傳一個既存物件,或是每次回傳一個新的物件(多半用於Dependency、Singleton情況,稍後會有詳細說明)。
l           透過特定的Factory建立一個物件,這個Factory可以依據組態檔的設定來建立物件(CustomFactory,隸屬於Enterprise Common Library)。
l           當物件擁有一個以上的建構子時,依據已有的參數,自動選取相容的建構子來建立要求的物件。(Consturctor Injection)
l           允許物件於建立後,透過程式或組態檔來賦值至屬性,或是呼叫特定的函式。(Setter Injection、Interface Injection)
l           提供一組Attribute,讓設計師可以指定需要Injection的屬性,亦或是於物件建立後需要呼叫的函式,也就是使用Reflection來自動完成Injection動作。
l           提供IBuilerAware介面,實作此介面的物件,ObjectBuilder會於建立該物件後,呼叫OnBuildUp或是OnTearDown函式。
l           提供TearDown機制,按建立物件的流程,反向釋放物件。
對於多數讀者來說,這些官方說明相當的隱誨,本文嘗試由架構角度切入,討論ObjectBuidler的主要核心概念,再透過實作讓讀者們了解,該如何使用ObjectBuidler
 
3-1The Architecture of Object Builder
 
圖2
2ObjectBuilder中四個主要核心物件的示意圖,BuidlerContext是一個概念型的環境物件,在這個物件中,包含著一組Strategys物件,一組Polices物件,一個Locator物 件, ObjectBuidler採用Strategys Pipeline(策略流)概念,設計師必須透過Strategy串列來建立物件,而Strategy會透過Polices來尋找『型別/id』對應的 Policy物件,使用她來協助建立指定的物件。此處有一個必須特別提出來討論的概念,Strategy在架構上是與型別無關的,每個 BuidlerContext會擁有一群Strategys物件,我們透過這個Strategys物件來建立任何型別的物件,不管建立的物件型別為何,都 會通過這個Strategys Pipeline。這意味著,當我們希望於建立A型別物件後呼叫函式A1,於建立B型別物件後呼叫函式 B1時,負責呼叫函式的Strategy物件會需 要一個機制來判別該呼叫那個函式,那就是Policy物件,BuilderContext中擁有一個Polices物件,其中存放著與『型別/id』對應 的Policy物件,如圖3所示。
圖3
值得一提的是,Policy是以Type/id方式,也就是『型別/id』方式來存放,這種做法不只可以讓不同型別擁有各自的Policy,也允許同型別但不同id擁有各自的PolicyObjectBuilder中的最後一個元素是LocatorLocator物件在ObjectBuidler中扮演著前述的Service Locator角色,設計師可以用Key/Value的方式,將物件推入Locator中,稍後再以Key值來取出使用。
 
3-2、Strategys
 
 ObjectBuilder內建了許多Strategy,這些Strategy可以大略分成四種類型,如圖4。
圖4
 
Pre-Creation Strategy
 
 Pre-Creation意指物件被建立前的初始動作,參與此階段的Strategy有:TypeMappingStrategyPropertyReflectionStrategyConstructorReflectionStrategyMethodReflectionStrategySingletonStrategy,稍後我們會一一檢視她們。
 
Creation Strategy
 
 Creation類型的Strategy主要工作在於建立物件,她會利用Pre-Creation Strategys所準備的參數來建立物件,ObjectBuilder就是運用Pre-CreationConstructorReflectionStrategyCreationStrategy來完成Constructor Injection動作。
 
Initialization Strategy
 
 當物件建立後,會進入初始化階段,這就是Initialization Strategy階段,在此階段中,PropertySetterStrategy會與PropertyReflectionStrategy合作,完成Setter Injection。而MethodExecutionStrategy則會與MethodReflectionStrategy合作,在物件建立後,呼叫特定的函式,也就是Method Injection(視使用方式,Interface Injection是以此種方式完成的)。
 
Post-Initialization Strategy
 
 在物件建立並完成初始化動作後,就進入了Post-Initialization Strategy階段,在此階段中,BuilderAwareStrategy會探詢已建立的物件是否實作了IBuilderAware介面,是的話就呼叫IBuilderAware.OnBuildUp函式。
 
關於物件釋放
 
 先 前曾經提過,ObjectBuidler在建立物件時,會一一呼叫所有Strategy來建立物件,同樣的!當釋放物件時,ObjectBuilder也 會進行同樣的動作,不過方向是相反的,在內建的Strategy中,只有BuilderAwareStrategy會參與物件釋放的動作,在物件釋放時, BuilderAwareStrategy會探詢欲釋放的物件是否實作了IBuidlerAware介面,是的話就呼叫 IBuidlerAware.OnTearDown函式。
 
3-3A Simple Application
 
   再怎麼詳細的說明,少了一個實例就很難讓人理解,本節以一個簡單的ObjectBuidler應用實例開始,一步步帶領讀者進入ObjectBuilder的世界。
程式10
using System;
using System.Collections.Generic;
using System.Text;
using Microsoft.Practices.ObjectBuilder;
 
namespace SimpleApp
{
    class Program
    {
        static void Main(string[] args)
        {
            Builder builder = new Builder();
            TestObject obj = builder.BuildUp<TestObject>(new Locator(), null, null);
            obj.SayHello();
            Console.ReadLine();
        }
    }
 
    public class TestObject
    {
        public void SayHello()
        {
            Console.WriteLine("TEST");
        }
    }
}
這是一個相當陽春的例子,在程式一開始時建立了一個Builder物件,她是ObjectBuilder所提供的Facade物件,其會預先建立一般常用的Strategy串列,並於BuilderUp函式被呼叫時,建立一個BuilderContext物件,並將Srategy串列及Polices串列指定給該BuilderContext,然後進行物件的建立工作。
 
How Object Creating
 
 要了解前面的例子中,TestObject物件究竟是如何被建立起來的,首先必須深入Builder物件的建構動作。
private StrategyList<TStageEnum> strategies = new StrategyList<TStageEnum>();
 
public BuilderBase()
{
}
 
public PolicyList Policies
{
           get { return policies; }
}
 
public StrategyList<TStageEnum> Strategies
{
           get { return strategies; }
}
 
public Builder(IBuilderConfigurator<BuilderStage> configurator)
{
                                Strategies.AddNew<TypeMappingStrategy>(BuilderStage.PreCreation);
                                Strategies.AddNew<SingletonStrategy>(BuilderStage.PreCreation);
                                Strategies.AddNew<ConstructorReflectionStrategy>(BuilderStage.PreCreation);
                                Strategies.AddNew<PropertyReflectionStrategy>(BuilderStage.PreCreation);
                                Strategies.AddNew<MethodReflectionStrategy>(BuilderStage.PreCreation);
                                Strategies.AddNew<CreationStrategy>(BuilderStage.Creation);
                                Strategies.AddNew<PropertySetterStrategy>(BuilderStage.Initialization);
                                Strategies.AddNew<MethodExecutionStrategy>(BuilderStage.Initialization);
                                Strategies.AddNew<BuilderAwareStrategy>(BuilderStage.PostInitialization);
 
                                Policies.SetDefault<ICreationPolicy>(new DefaultCreationPolicy());
 
                                if (configurator != null)
                                           configurator.ApplyConfiguration(this);
}
Buidler物件被建立時,其建構子會將前面所提及的幾個Strategys加到Strategies這個StrategyList Collection物件中,待BuildUp函式被呼叫時指定給新建立的BuilderContext物件。
public TTypeToBuild BuildUp<TTypeToBuild>(IReadWriteLocator locator,
string idToBuild, object existing, params PolicyList[] transientPolicies)
{
           return (TTypeToBuild)BuildUp(locator, typeof(TTypeToBuild), idToBuild, existing, transientPolicies);
}
 
public virtual object BuildUp(IReadWriteLocator locator, Type typeToBuild,
                                            string idToBuild, object existing, params PolicyList[] transientPolicies)
{
           ....................
                     return DoBuildUp(locator, typeToBuild, idToBuild, existing, transientPolicies);
...................
}
 
private object DoBuildUp(IReadWriteLocator locator, Type typeToBuild, string idToBuild, object existing,
                                PolicyList[] transientPolicies)
{
                     IBuilderStrategyChain chain = strategies.MakeStrategyChain();
..............
                     IBuilderContext context = MakeContext(chain, locator, transientPolicies);
..........................                          
                     object result = chain.Head.BuildUp(context, typeToBuild, existing, idToBuild);
.......................
                     }
 
private IBuilderContext MakeContext(IBuilderStrategyChain chain,
                                                     IReadWriteLocator locator, params PolicyList[] transientPolicies)
{
           .............
           return new BuilderContext(chain, locator, policies);
}
Builder的泛型函式BuildUp函式被呼叫後,其會呼叫非泛型的BuildUp函式,該函式會呼叫DoBuildUp函式,此處會透過strategies(先前於Builder建構子時初始化的StrategyList物件)來取得Strategys串列,並指定給稍後由MakeContext函式建立的BuilderContext,最後呼叫Strategy串列中第一個StrategyBuildUp函式來進行物件的建立動作。在這一連串的動作中,我們可以釐清幾個容易令人混淆的設計,第一!我們是透過Strategy串列,也就是IBuidlerStrategyChain.Head.BuildUp來建立物件,這個Head屬性就是Strategy串列中的第一個Strategy。第二!BuilderContext的作用在於,於呼叫各個Strategy.BuildUp函式時,給予她們存取此次建立動作所使用的StrategysPolicies等物件的機會。
 
Policy物件的用途
 
 現在,我們弄清楚了Strategy的用途,BuilderContext的真正涵意,但還有兩個元素尚未釐清,其中之一就是Policy物件,前面曾經稍微提過,Strategy是與型別無關的設計概念,因此為了針對不同型別做個別的處理,我們需要另一個與型別相關的設計,那就是Policy物件,要確認這點,必須重返Builder的建構子。
public Builder(IBuilderConfigurator<BuilderStage> configurator)
{
                          ..................
                                Policies.SetDefault<ICreationPolicy>(new DefaultCreationPolicy());
                .................
}
這裡呼叫了PoliciesSetDefault函式,Policies是一個PolicyList物件,其提供了推入(SetSetDefault)及取出(Get)函式,允許設計者針對所有『型別/id』及特定『型別/id』指定對應的IBuilderPolicy物件,那這有什麼用呢?這個問題可以由CreationStrategy類別中的以下這段程式碼來回答。
public override object BuildUp(IBuilderContext context, Type typeToBuild, object existing, string idToBuild)
{
           if (existing != null)
                     BuildUpExistingObject(context, typeToBuild, existing, idToBuild);
           else
                     existing = BuildUpNewObject(context, typeToBuild, existing, idToBuild);
           return base.BuildUp(context, typeToBuild, existing, idToBuild);
}
 
[SecurityPermission(SecurityAction.Demand, Flags = SecurityPermissionFlag.SerializationFormatter)]
private object BuildUpNewObject(IBuilderContext context, Type typeToBuild,
object existing, string idToBuild)
{
           ICreationPolicy policy = context.Policies.Get<ICreationPolicy>(typeToBuild, idToBuild);
.........................
           InitializeObject(context, existing, idToBuild, policy);
           return existing;
}
 
private void InitializeObject(IBuilderContext context, object existing, string id, ICreationPolicy policy)
{
           ................
           ConstructorInfo constructor = policy.SelectConstructor(context, type, id);
...................
           object[] parms = policy.GetParameters(context, type, id, constructor);
...............                 
method.Invoke(existing, parms);
}
如你所見,CreationStrategy於建立物件時,會由Policies中取出『型別/id』對應的ICreationPolicy物件,接著利用她來取得ConstructorInfo(建構子函式),再以GetParameters函式來取得建構子所需的參數,最後呼叫此建構子。這段程式碼告訴我們Policy的真正用途,就是用來協助Strategy於不同『型別/id』物件建立時,採取不同的動作,這也就是說,StrategyPolicy通常是成對出現的。
 
Locator
 
 最後一個尚未釐清的關鍵元素是Locator,我們於呼叫Builder的BuildUp函式時,建立了一個Locator物件並傳入該函式,這是用來做什麼的呢?在ObjectBuilder中,Locator扮演兩種角色,第一個角色是提供一個物件容器供Strategy使用,這點可以透過以下程式了解。
public class SingletonStrategy : BuilderStrategy
{
public override object BuildUp(IBuilderContext context, Type typeToBuild,
object existing, string idToBuild)
{
                     DependencyResolutionLocatorKey key = new DependencyResolutionLocatorKey(
typeToBuild, idToBuild);
                     if (context.Locator != null && context.Locator.Contains(key, SearchMode.Local))
                     {
                                TraceBuildUp(context, typeToBuild, idToBuild, "");
                                return context.Locator.Get(key);
                     }
                     return base.BuildUp(context, typeToBuild, existing, idToBuild);
}
}
SingletonStrategy是一個用來維持某一個物件只能有一份實體存在,當此Strategy被喚起時,其會先至Locator尋找目前要求的物件是否已被建立,是的話就取出該物件並傳回。Locator同時也可以作為一個Service Locator,這點可以由以下程式碼來驗證。
locator.Add("Test",new TestObject());
.............
TestObject obj = locator.Get<TestObject>("Test");
當然,這種手法有一個問題,那就是TestObject物件是預先建立後放在Locator中,這並不是一個好的設計,後面的章節我們會提出將Service LocatorDependency Injection整合的手法。
PS:ObjectBuidlerLocator離完善的Service Locator還有段距離。
 
四、Dependency Injection With ObjectBuilder
 
   ObjectBuilder支援Dependency Injection中定義的三種Injection模式,本章將一一介紹如何運用ObjectBuilder來實現。
 
4-1Constructor Injection
 
 Constructor Injection的精神在於使用建構子來進行注入動作,本節延用InputAccept的例子,程式11是改採ObjectBuilder進行Constructor Injection的例子。
程式11
using System;
using System.Collections.Generic;
using System.Text;
using System.Configuration;
using Microsoft.Practices.ObjectBuilder;
using Microsoft.Practices.EnterpriseLibrary.Common.Configuration.ObjectBuilder;
using Microsoft.Practices.EnterpriseLibrary.Common.Configuration;
 
namespace OB_ConstructorInjectionTest
{
    class Program
    {
        static void UseValueParameter(MyBuilderContext context)
        {
            ConstructorPolicy creationPolicy = new ConstructorPolicy();
            creationPolicy.AddParameter(new ValueParameter(typeof(IDataProcessor),
new PromptDataProcessor()));
            context.Policies.Set<ICreationPolicy>(creationPolicy, typeof(InputAccept), null);
        }
 
        static void Main(string[] args)
        {
            MyBuilderContext context = new MyBuilderContext(new Locator());
            context.InnerChain.Add(new CreationStrategy());
            UseValueParameter(context);
            InputAccept accept = (InputAccept)context.HeadOfChain.BuildUp(context,
typeof(InputAccept), null, null);
            accept.Execute();
            Console.Read();
        }
    }
 
    internal class MyBuilderContext : BuilderContext
    {
        public IReadWriteLocator InnerLocator;
        public BuilderStrategyChain InnerChain = new BuilderStrategyChain();
        public PolicyList InnerPolicies = new PolicyList();
        public LifetimeContainer lifetimeContainer = new LifetimeContainer();
 
        public MyBuilderContext()
            : this(new Locator())
        {
        }
 
        public MyBuilderContext(IReadWriteLocator locator)
        {
            InnerLocator = locator;
            SetLocator(InnerLocator);
            StrategyChain = InnerChain;
            SetPolicies(InnerPolicies);
 
            if (!Locator.Contains(typeof(ILifetimeContainer)))
                Locator.Add(typeof(ILifetimeContainer), lifetimeContainer);
        }
    }
 
    public class InputAccept
    {
        private IDataProcessor _dataProcessor;
 
        public void Execute()
        {
            Console.Write("Please Input some words:");
            string input = Console.ReadLine();
            input = _dataProcessor.ProcessData(input);
            Console.WriteLine(input);
        }
 
        public InputAccept(IDataProcessor dataProcessor)
        {
            _dataProcessor = dataProcessor;
        }
    }
   
    public interface IDataProcessor
    {
        string ProcessData(string input);
    }
 
    public class DummyDataProcessor : IDataProcessor
    {
 
        #region IDataProcessor Members
 
        public string ProcessData(string input)
        {
            return input;
        }
 
        #endregion
    }
 
    public class PromptDataProcessor : IDataProcessor
    {
        #region IDataProcessor Members
 
        public string ProcessData(string input)
        {
            return "your input is: " + input;
        }
 
        #endregion
    }
}
程式於一開始時,建立了一個MyBuilderContext物件,會自行建立BuilderContext物件而不使用Builder物件的目的很單純,就是為了釐清個別Strategy究竟做了那些事,這點在使用Builder物件時,會因為內建的Strategy都已加入,而顯得有些模糊。在MyBuilderContext物件建立後,此處將一個CreationStrategy加到Strategy串列中,CreationStrategy這個Strategy被歸類為Creation階段,是真正建立物件的Strategy,緊接著UseValueParameter函式會被呼叫,這個函式中建立了一個ConstructorPolicy物件,並呼叫其AddParameter函式,加入一個ValueParameter物件,這個ValueParameter物件就對應著InputAccept的建構子所需的參數,CreationStrategy於物件建立後,會透過BuilderContextPolicies來取得『型別/id』對應的ICreationPolicy物件(本例就是ConstructorPolicy物件), 然後呼叫ICreationPolicy.SelectionConstructor函式,這個函式必須根據呼叫者已用 ICreationPolicy.AddParameter所傳入的參數來選擇正確的建構子,然後再呼叫這個建構子並填入參數值來完成物件建立工作,圖5 是這整個流程的示意圖。
圖5
圖中讀者可能會有所迷惑的是,FormatterServices.GetSafeUninitializedObject函式是何作用?這是.NET Framework中一個建立物件的途徑,與一般new或是Activator.CreateInstance方式不同,GetSafeUninitializedObject函式並不會觸發該物件的建構子,只是單純的將物件建立起來而已,因此CreationStrategy才必須於最後呼叫對應的建構子。
 
Understanding Parameter
 
 程式11中使用了一個ValueParameter物件,要知道這個物件的作用,我們得先了解ParameterObjectBuilder中所代表的意義,在三種注入模式中,有一個共通的規則,就是需要有參數來注入,Constructor Injection是透過建構子參數注入,而Interface Injection則是透過函數參數注入,Setter Injection則是透過屬性注入,因此參數是這三種注入模式都會用到的觀念,所以ObjectBuilder定義了IParameter介面,並提供一組實作此介面的參數物件,於注入時期由這些參數物件來取得參數值,如圖6
6
 
ValueParameter
 
 這是一個最簡單的Paramter物件,建構子如下所示:
public ValueParameter(Type valueType, object value)
她的GetValue函式僅是將建構子傳入的value物件傳回而已。
 
DependencyParamter
 
 DependencyParameter是一個功能強大的Parameter物件,程式12是以DependencyParameter來取代ValueParameter完成Constructor Injection的例子。
程式12
static void UseDependencyParameter(MyBuilderContext context)
{
      ConstructorPolicy creationPolicy = new ConstructorPolicy();
      creationPolicy.AddParameter(new DependencyParameter(typeof(IDataProcessor),null,
typeof(PromptDataProcessor),NotPresentBehavior.CreateNew,SearchMode.Local));
      context.Policies.Set<ICreationPolicy>(creationPolicy, typeof(InputAccept), null);
 
      ConstructorPolicy creationPolicy2 = new ConstructorPolicy();
      context.Policies.Set<ICreationPolicy>(creationPolicy2, typeof(PromptDataProcessor),null);
}
讀者可以發現,DependencyParameter並未要求建構者傳入任何物件實體,而是要求建構者傳入注入時對應的參數型別、參數名稱、實體型別、NotPersentBehavoir及SearchMode等參數,下面的程式列表是DependencyParameter的建構子:
public DependencyParameter(Type parameterType, string name,
                                 Type createType, NotPresentBehavior notPresentBehavior, SearchMode searchMode)
第一個參數是參數的型別,第二個參數是參數的名稱,當ConstructorPolicySelectConstructor函式時,會依據這兩個參數來選取適合的建構子,第三個參數是實體物件的型別,以本例來說,就是以PromptDataProcessor這個型別建立物件來傳入需要IDataProcessor型別的建構子、函式或屬性,第四個參數則影響了DependencyParameter的取值動作,預設情況下,DependencyParameter會先至Locator中取值,這個動作會受到第五個參數:SearchMode的影響(稍後會介紹這一部份),如果找不到的話,就會依據此參數值來做動作,NotPersentBehavior這個列舉的定義如下:
public enum NotPresentBehavior
{                  
           CreateNew,
           ReturnNull,
           Throw,
}
CreateNew代表著當DependencyParameterLocator找不到需要的值時,呼叫BuilderContext.HeadOfChain.BuildUp函 式來建立該物件,以此例來說即是如此,所建立物件的型別就是PromptDataProcessor。ReturnNull則是回傳一個Null值, Throw則是直接拋出一個例外。好了,了解了整體流程後,現在讓我們一一釐清這個流程中剩下的部份,第一!於Locator找尋需要的值是什麼意思,試 想一種情況,當我們在做Dependency Injection時,是否有某些欲注入物件是可重用的,也就是該物件可以只建立一個,注入多個不同的物件,讓這些物件共用這個注入物件,這就是 DependencyParameter會先至Locator中找尋已推入的注入物件的原因,請參考程式13的例子。
程式13
static void UseDependencyParameter(MyBuilderContext context)
{
     context.InnerLocator.Add(new DependencyResolutionLocatorKey(typeof(IDataProcessor), null),
new PromptDataProcessor());
 
     ConstructorPolicy creationPolicy = new ConstructorPolicy();
     creationPolicy.AddParameter(new DependencyParameter(typeof(IDataProcessor),
null,typeof(PromptDataProcessor),NotPresentBehavior.CreateNew,SearchMode.Local));
      context.Policies.Set<ICreationPolicy>(creationPolicy, typeof(InputAccept), null);
 
      ConstructorPolicy creationPolicy2 = new ConstructorPolicy();
      context.Policies.Set<ICreationPolicy>(creationPolicy2, typeof(PromptDataProcessor),null);
}
這個例子預先建立了一個PromptDataProcessor物件,並以 DependencyResolutionLocatorKey封裝後推入Locator中,這樣一來,當DependencyParameter取值 時,就會依據參數的『型別/id』至Locator找尋需要的值,此時就會得到我們所推入的PromptDataProcessor物件,而不是建立一個 新的,另外!只要於AddParameter所傳入的DependencyParameter是以IDataProcessor為參數型別,並以null 為id(名稱)的話,那麼永遠都會傳回我們所推入Locator的PromptDataProcessor物件。第二個要釐清的是SearchMode的 涵意,在ObjectBuilder的架構上,Locator是可以有Parent/Child關係的,當DependencyParameter要找尋 需要的物件時,如果SearchMode是Local的話,那麼這個搜尋動作只會搜尋該Locator自身,如果是Up的話,那麼在該Locator自身 搜尋不到時,就會往Parent Locator搜尋。第三個要釐清的是第二個ConstructorPolicy的建立動作,還記得嗎?我們提過Policy是『型別/id』相關的,當 DependencyParameter無法於Locator找到需要的物件而透過BuildUp來建立物件時,該『型別/id』同樣需要一個 ICreationPolicy來對應,否則將會引發Missing Policy的例外,注意!DependencyParameter所使用的name參數必須與設定Set< ICreationPolicy>時所傳入的第三個參數相同。最後一個問題是,如果每個『型別/id』都要設定對應的 ICreationPolicy,豈不累人,ObjectBuilder當然沒有這麼不人性化,我們可以呼叫Policies.SetDefault來為 所有『型別/id』預設一個ICreationPolicy,如程式14所示。
程式14
static void UseDependencyParameter(MyBuilderContext context)
{
    ConstructorPolicy creationPolicy = new ConstructorPolicy();
    creationPolicy.AddParameter(new DependencyParameter(typeof(IDataProcessor),
null,typeof(PromptDataProcessor),NotPresentBehavior.CreateNew,SearchMode.Local));
 context.Policies.Set<ICreationPolicy>(creationPolicy, typeof(InputAccept), null);
 
   context.Policies.SetDefault<ICreationPolicy>(new ConstructorPolicy());
}
 
CreationParameter
 
 DependencyParameter相同,CreationParameter也會透過BuildUp來建立物件,不同的是其不會先搜尋Locator,也無法作參數型別與實體型別對應,因此無法適用於InputAccept這種以介面為介質的注入方式,必須與TypeMappingStrategy(後述)合用才能解決,如程式15所示。
程式15
static void UseCreationParameter(MyBuilderContext context)
{
       ConstructorPolicy creationPolicy = new ConstructorPolicy();
       creationPolicy.AddParameter(new CreationParameter(typeof(IDataProcessor)));
       context.Policies.Set<ICreationPolicy>(creationPolicy, typeof(InputAccept), null);
 
       TypeMappingPolicy mappingPolicy = new TypeMappingPolicy(typeof(PromptDataProcessor), null);
       context.Policies.Set<ITypeMappingPolicy>(mappingPolicy, typeof(IDataProcessor), null);
 
      context.Policies.SetDefault<ICreationPolicy>(new ConstructorPolicy());
}
 
static void Main(string[] args)
{
       MyBuilderContext context = new MyBuilderContext(new Locator());
       context.InnerChain.Add(new TypeMappingStrategy());
      context.InnerChain.Add(new CreationStrategy());
       UseCreationParameter(context);
       InputAccept accept = (InputAccept)context.HeadOfChain.BuildUp(context,
typeof(InputAccept), null, null);
       accept.Execute();
      Console.Read();
}
 
CloneParameter
 
 CloneParameter的建構子接受一個IParameter參數,當其GetValue函式被呼叫時,會透過從建構子指定的Parameter物件來取值,如果取得的值是實作了ICloneable介面的物件時,其將呼叫Clone函式來拷貝該值,否則傳回原值,下面的程式片斷是CloneParametr的建構子宣告。
public CloneParameter(IParameter param)
 
LookupParameter
 
 LookupParameter的建構子接受一個object型別的參數,當GetValue函式被呼叫時,會經由Locator.Get函式,以建構子所傳入的參數為鍵值,取得位於Locator中的值,下面的程式片斷為LookupParameter的建構子宣告。
public LookupParameter(object key)
程式16則是將InputAccept範例改為使用LookupParameter的版本。
程式16
static void UseLookupParameter(MyBuilderContext context)
{
          context.InnerLocator.Add("dataProcessor", new PromptDataProcessor());
          ConstructorPolicy creationPolicy = new ConstructorPolicy();
          creationPolicy.AddParameter(new LookupParameter("dataProcessor"));
          context.Policies.Set<ICreationPolicy>(creationPolicy, typeof(InputAccept), null);
          context.Policies.SetDefault<ICreationPolicy>(new ConstructorPolicy());
}
 
InjectionConstructor Attribute
 
 使用Paramerer物件來進行Consturctor Injection時, 設計者必須在建立物件前,預先準備這些Parameter物件,雖然動作不算繁鎖,但若全部物件的建立都要這麼做,未免有些沒有效率,為此! ObjectBuilder提供了另一種較為簡單的方法,就是利用InjectionConstructor這個Attribute,再搭配上 ConstructorReflectionStrategy物件,自動的為設計者準備這些Parmeter物件,程式17是修改為 InjectionConstructor模式的版本。
程式17
static void UseInjectionConstructorAttribute(MyBuilderContext context)
{
       context.InnerChain.Add(new ConstructorReflectionStrategy());
       context.InnerChain.Add(new CreationStrategy());      
}
 
..........
public class InputAccept
{
    private IDataProcessor _dataProcessor;
 
     public void Execute()
     {
         Console.Write("Please Input some words:");
         string input = Console.ReadLine();
         input = _dataProcessor.ProcessData(input);
         Console.WriteLine(input);
     }
 
    [InjectionConstructor]
    public InputAccept([Dependency(Name="dataProcessor",
CreateType=typeof(PromptDataProcessor))]IDataProcessor dataProcessor)
   {
         _dataProcessor = dataProcessor;
    }
}
要使用InjectionConstructor Attribute,我們必須在CreationStrategy這個Strategy前加入一個ConstructorReflectionStrategy物件,她會於建立物件動作時,探詢欲建立物件型別所提供的所有建構子,選取已標上InjectionConstrucor Attribute的那個為指定建構子,接著ConstructorReflectionStrategy會探詢該建構子的所有參數,查看是否標上Dependency Attribute,是的話就以其設定建立DependencyParameter,否則建立一個新的DependencyParameter,她會單以型別參數來建立DependencyParameter,最後ConstructorReflectionStrategy會以這些資訊來建立對應的ConstructorPolicy物件,完成整個物件建立動作。
 
Understanding Dependency Attribute
 
 ConstructorReflectionStrategy依賴兩個關鍵的Attribute,一個是用來標示指定建構子的InjectionConstructor Attribute,另一個則是用來標示參數該如何取得的Dependency Attribute,此Attribute有四個屬性,分別對應到DependencyParameter的四個屬性,如表2
2
DependencyAttribute
DependencyParameter
說明
Name
Name
id(名稱)
CreateType
CreateType
欲建立物件的實體型別
NotPersentBehavior
NotPersentBehavior
當欲建立物件無法由Locator取得時的行為模式。
SearchMode
SearchMode
Locator的搜尋法則。
使用Dependency AttributeConsturctorReflectionStrategy模式的優點是設計者不需花費時間一一建立Parameter物件,而缺點就是CreateType參數,由於ConstructorReflectionStrategy依賴著Dependency AttributeCreateType參數來決定實際建立物件的型別,這使得設計者必須在標示Dependency Attribute時,一併指定這個參數,否則ConstructorReflectionStrategy將會以參數型別做為建立實際物件時的型別,而在本例中,我們無法建立一個IDataProcessor物件,這點降低了程式的可訂制性。那這要如何解決呢?簡單的方法是撰寫一個新的Dependency Attribute、或是使用TypeMappingStrategy,複雜的則是撰寫一個新的ConstructorReflectionStrategy,後面的章節我們會再重訪這個問題。
 
Injection with DependencyResolutionLocator
 
 前面談到DependencyParameter時曾經提過,她會先至Locator中搜尋需要的參數值,那麼這也意味著,在使用ConstructorReflectionStrategy時,我們可以將參數值先行推入Locator中,這樣就可以避開指定CreateType了,如程式18所示。
程式18
static void UseDependencyResolution(MyBuilderContext context)
{
      context.InnerChain.Add(new ConstructorReflectionStrategy());
      context.InnerChain.Add(new CreationStrategy());
     context.InnerLocator.Add(new DependencyResolutionLocatorKey(typeof(IDataProcessor),
"dataProcessor"),new PromptDataProcessor());            
}
 
[InjectionConstructor]
public InputAccept([Dependency(Name="dataProcessor")]IDataProcessor dataProcessor)
當然,這仍然會有一個問題,那就是必須預先建立PromptDataProcessor物件,而非於InputAccept物件建立時期建立,這是在不撰寫自定Dependency Attribute或Strategy,亦或是使用TypeMappingStrategy情況下的簡易解法。
 
DefaultCreationPolicy and ConstructorPolicy
 
 ObjectBuilder內建了兩個ICreationPolicy的實作體,一是前面所使用的ConsturoctPolicy,二是DefaultCreationPolicy,與ConstructorPolicy不同,DefaultCationPolicy永遠使用預設的建構子,如下所示。
public ConstructorInfo SelectConstructor(IBuilderContext context, Type type, string id)
{
           if (constructor != null)
                     return constructor;
 
           List<Type> types = new List<Type>();
foreach (IParameter parm in parameters)
                     types.Add(parm.GetParameterType(context));
 
           return type.GetConstructor(types.ToArray());
}
而呼叫該建構子時所需的參數,則直接以BuildUp函式,依據參數的『型別/id』來建立,沒有與Parameter的互動。
public object[] GetParameters(IBuilderContext context, Type type, string id, ConstructorInfo constructor)
{
           ParameterInfo[] parms = constructor.GetParameters();
           object[] parmsValueArray = new object[parms.Length];
 
           for (int i = 0; i < parms.Length; ++i)
                     parmsValueArray[i] = context.HeadOfChain.BuildUp(context, parms[i].ParameterType, null, id);
 
           return parmsValueArray;
}
由此可見,DefaultCreationPolicy有兩個特色,一是其會選擇頂端的建構子,二是其一律以BuidUp函 式依據參數型別來建立參數物件,不需要設計者介入。那在何種情況下選擇DefaultCreationPolicy呢?一般來說,使用 ConstructorPolicy時,因為其會依據設計者所加入的Parameter物件來選擇建構子,如果設計者未準備這些,那麼 ConstructorPolicy將因無法取得適合的建構子而引發例外,雖然這點可以經由搭配 ConstructorReflectionStrategy來解決,但使用ConstructorReflectionStrategy時必須搭配 Dependency Attribtue及InjectionConstructor Attribute,所以也是個負擔。使用DefaultCreationPolicy就沒有這些問題了,缺點則是無法指定實際建立的參數物件型別,所以 DefautlCreationPolicy通常被設定成預設的ICreationPolicy,主要作用在於當我們所建立的物件是簡單的,只有一個建構 子,且不需要特別指定參數實際型別時,就交由她來處理,而需要特別處理的,就運用『型別/id』對應的ConstructorPolicy或是 Dependency Attribute、Injection Constructor Attrbute搭配ConstructorReflectionStrategy來處理。
 
4-2Interface Injection
 
 Interface InjectionObjectBuidler中可以經由Method Injection來完成,指的是在物件建立後,呼叫所指定的函式來完成初始化動作,而負責這個工作的就是MethodExecutionStrategy,本節持續延應InputAccept來示範如何於ObjectBuidler中實現Interface Injection。
 
MethodExecutionStrategy
 
 要實現Interface Injection,除了必須使用CreationStrategy來建立物件外,還要使用另一個StrategyMethodExecutionStrategy,她會在物件建立完成後,執行指定的函式,程式19是使用MethodExecutionStrategy來實現Interface Injection的例子。
程式19
static void UseMethodInfo(MyBuilderContext context)
{
       context.InnerChain.Add(new CreationStrategy());
       context.InnerChain.Add(new MethodExecutionStrategy());
 
       IMethodCallInfocallInfo = new MethodCallInfo("SetDataProcessor",
new ValueParameter(typeof(IDataProcessor), new PromptDataProcessor()));
       IMethodPolicy policy = new MethodPolicy();
       policy.Methods.Add("SetDataProcessor", callInfo);
       context.Policies.Set<IMethodPolicy>(policy, typeof(InputAccept), null);
}
 
static void Main(string[] args)
{
       MyBuilderContext context = new MyBuilderContext(new Locator());                      
      UseDependencyAttribute(context);
       context.Policies.SetDefault<ICreationPolicy>(new DefaultCreationPolicy());
       InputAccept accept = (InputAccept)context.HeadOfChain.BuildUp(context, typeof(InputAccept),
null, null);
       accept.Execute();
       Console.Read();
}
 
public class InputAccept
{
     private IDataProcessor _dataProcessor;
 
     public void SetDataProcessor(IDataProcessor dataProcessor)
     {
          _dataProcessor = dataProcessor;
     }
 
     public void Execute()
     {
         Console.Write("Please Input some words:");
         string input = Console.ReadLine();
         input = _dataProcessor.ProcessData(input);
         Console.WriteLine(input);
     }
}
此處使用ValueParameter來進行呼叫指定函式時的參數注入動作,在使用MethodExecutionStrategy時,設計者必須先行建立呼叫函式時所需的MethodCallInfo物件,這是一個實作IMethodInfo介面的物件,設計者必須於此物件中指定欲呼叫的函式、及傳入的Parameter物件,下面是MethodInfo的建構子宣告。
public MethodCallInfo(string methodName)
public MethodCallInfo(string methodName, params object[] parameters)
public MethodCallInfo(string methodName, params IParameter[] parameters)
public MethodCallInfo(string methodName, IEnumerable<IParameter> parameters)
public MethodCallInfo(MethodInfo method)
public MethodCallInfo(MethodInfo method, params IParameter[] parameters)
public MethodCallInfo(MethodInfo method, IEnumerable<IParameter> parameters)
MethodInfo擁有許多重載的建構子,大概分成兩大類:函式名稱及MethodInfo物件,每類會分成四個,分別是無參數、使用params傳入參數值、使用params傳入IParamete物件、傳入IEnumerable<IParameter>物件。在MethodInfo物件建立後,接著就要將這些物件傳入IMethodPolicy物件,並指定給context.Policies物件,這樣就完成了Interface Injection的準備動作,之後建立InputAccept物件後,SetDataProcess函式就會被呼叫,同時會傳入指定的PromptDataProcessor物件。
 
How MethodExecutionStrategy Working
 
 MethodExecutionStrategyBuildUp函式被呼叫時,會透過context.Policies來取得型別對應的IMethodPolicy物件,如下所示。
IMethodPolicy policy = context.Policies.Get<IMethodPolicy>(type, id);
然後會透過IMethodPolicy物件來取得所有需要處理的IMethodCallInfo物件,並一一呼叫其SelectMethod函式來取得欲呼叫函式,如下所示。
MethodInfo methodInfo = methodCallInfo.SelectMethod(context, type, id);
SelectMethod函式會依據當初建立此IMethodCallInfo物件時所指定的函式名稱、參數數量及型別來取得對應函式的MethodInfo物件。於取得MethodInfo物件後,緊接著就是透過IMethodCallInfo.GetParameters函式來取得呼叫此函式時需傳入的參數值,如下所示。
object[] parameters = methodCallInfo.GetParameters(context, type, id, methodInfo);
最後呼叫MethodInfo.Invoke函式來呼叫該函式就完成整個動作了。
methodInfo.Invoke(obj, parameters);
好了,這就是MethodExecutionStrategy的整個流程,現在我們要釐清幾個可能會令人困惑的問題,第一!當欲呼叫的函式是重載,有多個同名函式時,SelectMethod依據什麼來決定要呼叫那一個?答案是參數數量及型別。第二!當使用Parameter物件傳入MethodCallInfo物件的建構子時,GetParameters函式會透過Parameter.GetValue來取值,那麼當直接以object[]方式傳入MethodCallInfo的建構子時呢?答案是該建構子會逐個為傳入的object建立ValueParameter物件,如下所示。
public MethodCallInfo(string methodName, params object[] parameters)
                                :this(methodName, null, ObjectsToIParameters(parameters))
{
}
 
private static IEnumerable<IParameter> ObjectsToIParameters(object[] parameters)
{
           List<IParameter> results = new List<IParameter>();
           if (parameters != null)
                     foreach (object parameter in parameters)
                                results.Add(new ValueParameter(parameter.GetType(), parameter));
           return results.ToArray();
}
最後一個問題是,可以進行一個以上的函式呼叫嗎?答案是可以,建立對應的MethodCallInfo物件,並加到IMethodPolicy後即可,呼叫的順序則是依照MethodCallInfo加入IMethodPolicy的順序。。
 
Use DependencyParameter
 
 Constructor Injection相同,你也可以使用DependencyParameter來進行Interface Injection動作,如程式20
程式20
static void UseDependencyParameter(MyBuilderContext context)
{
      context.InnerChain.Add(new CreationStrategy());
      context.InnerChain.Add(new MethodExecutionStrategy());
 
     MethodCallInfo callInfo = new MethodCallInfo("SetDataProcessor",
new DependencyParameter(typeof(IDataProcessor), "dataProcessor", typeof(PromptDataProcessor), NotPresentBehavior.CreateNew, SearchMode.Local));
      IMethodPolicy policy = new MethodPolicy();
      policy.Methods.Add("SetDataProcessor", callInfo);
      context.Policies.Set<IMethodPolicy>(policy, typeof(InputAccept), null);
}
 
use MethodReflectionStrategy
 
 如同ConstructorReflectionStrategy的作用一樣,ObjectBuilder也提供了供Method Injection使用的MethodReflectionStrategy物件,要使用她,我們必須為欲進行Method Injection的函式標上InjectionMethod Attribute,如程式21所示。
程式21
static void UseDependencyResolverLocator(MyBuilderContext context)
{
       context.InnerChain.Add(new CreationStrategy());
      context.InnerChain.Add(new MethodReflectionStrategy());
       context.InnerChain.Add(new MethodExecutionStrategy());
 
      context.InnerLocator.Add(new DependencyResolutionLocatorKey(typeof(IDataProcessor),
"dataProcessor"), new PromptDataProcessor());
}
 
public class InputAccept
{
     private IDataProcessor _dataProcessor;
 
        [InjectionMethod]
        public void SetDataProcessor(
[Dependency(Name="dataProcessor"))]IDataProcessor dataProcessor)
        {
            _dataProcessor = dataProcessor;
        }
        ...........
}
本例使用DependencyResolutionLocatorKey模式進行注入動作,有了Constructor Injection部份的解說,相信讀者對這種模式已經了然於胸了。
 
Injection with Dependency Attribute and CreateType
 
   同樣的,我們也可以在Dependency Attribute中指定CreateType來達到同樣的效果,如程式22所示。
程式22
static void UseDependencyAttribute(MyBuilderContext context)
{
      context.InnerChain.Add(new CreationStrategy());
     context.InnerChain.Add(new MethodReflectionStrategy());
      context.InnerChain.Add(new MethodExecutionStrategy());
}
 
public class InputAccept
{
     private IDataProcessor _dataProcessor;
 
     [InjectionMethod]
    public void SetDataProcessor(
[Dependency(Name="dataProcessor",
CreateType=typeof(PromptDataProcessor))]IDataProcessor dataProcessor)
        {
            _dataProcessor = dataProcessor;
        }
.............
}
 
4-3Setter Injection
 
 ObjectBuilder使用PropertySetterStrategy來進行Setter Injection,用法與前述的Interface Injection模式大致相同,如程式23所示。
程式23
static void UsePropertySetter(MyBuilderContext context)
{
      context.InnerChain.Add(new CreationStrategy());
      context.InnerChain.Add(new PropertySetterStrategy());
     PropertySetterPolicy policy = new PropertySetterPolicy();
      policy.Properties.Add("DataProcessor", new PropertySetterInfo("DataProcessor",
new ValueParameter(typeof(IDataProcessor), new PromptDataProcessor())));
     context.Policies.Set<IPropertySetterPolicy>(policy, typeof(InputAccept), null);
}
 
static void Main(string[] args)
{
     MyBuilderContext context = new MyBuilderContext(new Locator());
      UsePropertySetter(context);
      context.Policies.SetDefault<ICreationPolicy>(new DefaultCreationPolicy());
      InputAccept accept = (InputAccept)context.HeadOfChain.BuildUp(context,
typeof(InputAccept), null, null);
      accept.Execute();
      Console.Read();
}
 
public class InputAccept
{
    private IDataProcessor _dataProcessor;
 
    public IDataProcessor DataProcessor
    {
       get
       {
           return _dataProcessor;
       }
       set
      {
          _dataProcessor = value;
       }
 }
 
 public void Execute()
 {
       Console.Write("Please Input some words:");
       string input = Console.ReadLine();
       input = _dataProcessor.ProcessData(input);
       Console.WriteLine(input);
    }
 }
設計者必須預先建立PropertySetterInfo物件,並為其指定欲設定的屬性名稱及參數,PropertySetterInfo是一個實作了IPropertySetterInfo介面的物件,其建構子宣告如下。
public PropertySetterInfo(string name, IParameter value)
public PropertySetterInfo(PropertyInfo propInfo, IParameter value)
有了MethodCallInfo的經驗,讀者們對這些建構子應該不會有任何疑惑,應該會抱怨其不像MethodCallInfo般提供那麼多的選擇吧()。在ProeprtySetterInfo建立後,接著只要將其加到IPropertySetterPolicy物件中,並依『型別/id』指定給context.Policies即可完成Setter Injection
 
How PropertySetterStrategy Work
 
 PropertySetterStrategyBuildUp函式被呼叫時,會透過context.Policies來取得型別對應的IPropertySetterPolicy物件,如下所示。
IPropertySetterPolicy policy = context.Policies.Get<IPropertySetterPolicy>(type, id);
然後會透過IMethodPoliIPropertySetterPolicyy物件來取得所有需要處理的IPropertySetterInfo物件,並一一呼叫其SelectProperty函式來取得欲設定的屬性,如下所示。
PropertyInfo propInfo = propSetterInfo.SelectProperty(context, type, id);
SelectProperty函式會依據當初建立此IPropertySetterInfo物件時所指定的屬性名稱、參數來取得對應屬性的PropertyInfo物件。於取得PropertyInfo物件後,緊接著就是透過IPropertySetterInfo.GetValue函式來取得設定此屬性時需傳入的值,如下所示。
object value = propSetterInfo.GetValue(context, type, id, propInfo);
最後呼叫PropertyInfo.SetValue函式來設定屬性值就完成整個動作了。
propInfo.SetValue(obj, value, null);
這就是整個Setter Injection的流程,這裡只有一個問題,我們可以設定一個以上的屬性嗎?答案是肯定的,只要建立對應數量的PropertySetterInfo物件即可。
 
use DependencyParameter
 
 同樣的,使用DependencyParameter也可以達到同樣的效果,如程式24
程式24
static void UseDependencyParameter(MyBuilderContext context)
{
       context.InnerChain.Add(new CreationStrategy());
       context.InnerChain.Add(new PropertySetterStrategy());
       PropertySetterPolicy policy = new PropertySetterPolicy();
       policy.Properties.Add("DataProcessor", new PropertySetterInfo("DataProcessor",
                            new DependencyParameter(typeof(IDataProcessor),"DataProcessor",
typeof(PromptDataProcessor),NotPresentBehavior.CreateNew,SearchMode.Local)));
       context.Policies.Set<IPropertySetterPolicy>(policy, typeof(InputAccept), null);
}
 
use PropertyReflectionStrategy
 
 相對於ConsturctorReflectionStrategyMethodReflectionStrategy,ObjectBuilder也提供了一個同類型的PropertyReflectionStrategy,我們可以搭配Dependency Attribute及DependencyResolutionLocatorKey物件來達到同樣效果,如程式25。
程式25
static void UseDependencyResolutionLocator(MyBuilderContext context)
{
      context.InnerChain.Add(new CreationStrategy());
      context.InnerChain.Add(new PropertyReflectionStrategy());
      context.InnerChain.Add(new PropertySetterStrategy());
     context.Locator.Add(new DependencyResolutionLocatorKey(typeof(IDataProcessor),
"DataProcessor"), new PromptDataProcessor());
}
 
public class InputAccept
{
     private IDataProcessor _dataProcessor;
 
     [Dependency(Name="DataProcessor")]
     public IDataProcessor DataProcessor
     {
        get
        {
            return _dataProcessor;
        }
        set
        {
            _dataProcessor = value;
        }
    }
.........
}
 
Injection with Dependency Attribute and CreateType
 
 我們也可以使用Dependency AttributeCreateType參數來進行Setter Injection,如程式26
程式26
static void UseDependencyAttribute(MyBuilderContext context)
{
      context.InnerChain.Add(new CreationStrategy());
      context.InnerChain.Add(new PropertyReflectionStrategy());
      context.InnerChain.Add(new PropertySetterStrategy());
}
 
public class InputAccept
{
    private IDataProcessor _dataProcessor;
 
   [Dependency(Name="DataProcessor",CreateType=typeof(PromptDataProcessor))]
   public IDataProcessor DataProcessor
   {
       get
       {
           return _dataProcessor;
       }
       set
       {
           _dataProcessor = value;
       }
    }
...............
}