三、ObjectBuilder Application Block

ObjectBuilder一開始出現于Microsoft所提出的Composite UI Application Block，主司對象的建立及釋放工作， 它實現了本文前面所提及的Dependency Injection概念，同時在架構上提供了高度的延展性。運用ObjectBuilder來建立對象，設計師可以透過程序或組態文件，對對象建立與釋放的流程進行細部的調整，例如改變對象建立時所調用的Constructor(構造函數)，調整傳入的參數，于對象建立后調用特定方法等等。鑒于ObjectBuilder的功能逐漸完整，加上社群對于Dependency Injection實現對象的強烈需求，Microsoft正式將ObjectBuilder納入Enterprise Library 2006中，并修改Caching、Logger、Security、Data Access等Application Block的底層，令其于ObjectBuilder整合，以此增加這些Application Block的延展性。就官方文件的說明，ObjectBuilder Application Block提供以下的功能。

• 允許要求一個抽象對象或接口，ObjectBuilder會依據程序或組態文件的設定，傳回一個實體對象。
• 回傳一個既存對象，或是每次回傳一個新的對象(多半用于Dependency、Singleton情況，稍后會有詳細說明)。
• 透過特定的Factory建立一個對象，這個Factory可以依據組態文件的設定來建立對象(CustomFactory，隸屬于Enterprise Common Library)。
• 當物件擁有一個以上的構造函數時，依據已有的參數，自動選取兼容的構造函數來建立要求的對象。(Consturctor Injection)
• 允許對象于建立后，透過程序或組態文件來賦值至屬性，或是調用特定的方法。(Setter Injection、Interface Injection)
• 提供一組Attribute，讓設計師可以指定需要Injection的屬性，亦或是于對象建立后需要調用的方法，也就是使用Reflection來自動完成Injection動作。
• 提供IBuilerAware接口，實現此接口的對象，ObjectBuilder會于建立該對象后，調用OnBuildUp或是OnTearDown方法。
• 提供TearDown機制，按建立對象的流程，反向釋放對象。

對于多數讀者來說，這些官方說明相當的隱誨，本文嘗試由架構角度切入，討論ObjectBuidler的主要核心概念，再透過實現讓讀者們了解，該如何使用ObjectBuidler。

3-1、The Architecture of Object Builder

圖2

圖2是ObjectBuilder中四個主要核心對象的示意圖，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擁有各自的Policy。ObjectBuilder中的最后一個元素是Locator，Locator對象在ObjectBuidler中扮演著前述的Service Locator角色，設計師可以用Key/Value的方式，將對象推入Locator中，稍后再以Key值來取出使用。

3-2、Strategys

ObjectBuilder內建了許多Strategy，這些Strategy可以大略分成四種類型，如圖4。

圖4

• Pre-Creation Strategy

Pre-Creation意指對象被建立前的初始動作，參與此階段的Strategy有：TypeMappingStrategy、PropertyReflectionStrategy、ConstructorReflectionStrategy、MethodReflectionStrategy及SingletonStrategy，稍后我們會一一檢視 它們。

• Creation Strategy

Creation類型的Strategy主要工作在于建立對象，它會利用Pre-Creation Strategys所準備的參數來建立對象，ObjectBuilder就是運用Pre-Creation的ConstructorReflectionStrategy及CreationStrategy來完成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-3、A 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串行中第一個Strategy的BuildUp方法來進行對象的建立動作。在這一連串的動作中，我們可以厘清幾個容易令人混淆的設計，第一！我們是透過Strategy串行，也就是IBuidlerStrategyChain.Head.BuildUp來建立對象，這個Head屬性就是Strategy串行中的第一個Strategy。第二！BuilderContext的作用在于，于調用各個Strategy.BuildUp方法時，給予 它們存取此次建立動作所使用的Strategys及Policies等對象的機會。

• Policy物件的用途

現在，我們弄清楚了Strategy的用途，BuilderContext的真正涵意，但還有兩個元素尚未厘清，其中之一就是Policy對象，前面曾經稍微提過，Strategy是與類型無關的設計概念，因此為了針對不同類型做個別的處理，我們需要另一個與類型相關的設計，那就是Policy對象，要確認這點，必須重返Builder的構造函數。

public Builder(IBuilderConfigurator<BuilderStage> configurator)
{
??? ..................
??? Policies.SetDefault<ICreationPolicy>(new DefaultCreationPolicy());
??? .................
}

這里調用了Policies的SetDefault方法，Policies是一個PolicyList對象，其提供了推入(Set、SetDefault)及取出(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』對象建立時，采取不同的動作，這也就是說，Strategy與Policy通常是成對出現的。

• 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 Locator與Dependency Injection整合的手法。

PS:ObjectBuidler的Locator離完善的Service Locator還有段距離。

四、Dependency Injection With ObjectBuilder

ObjectBuilder支持Dependency Injection中定義的三種Injection模式，本章將一一介紹如何運用ObjectBuilder來實現。

4-1、Constructor 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于對象建立后，會透過BuilderContext的Policies來取得『類型/id』對應的ICreationPolicy對象(本例就是ConstructorPolicy對象)，然后調用ICreationPolicy.SelectionConstructor方法，這個方法必須根據調用者已用ICreationPolicy.AddParameter所傳入的參數來選擇正確的構造函數，然后再調用這個構造函數并填入參數值來完成對象建立工作，圖5是這整個流程的示意圖。

圖5

圖中讀者可能會有所迷惑的是，FormatterServices.GetSafeUninitializedObject方法是何作用？這是.NET Framework中一個建立對象的途徑，與一般new或是Activator.CreateInstance方式不同，GetSafeUninitializedObject方法并不會觸發該對象的構造函數，只是單純的將對象建立起來而已，因此CreationStrategy才必須于最后調用對應的構造函數。

• Understanding Parameter

程序11中使用了一個ValueParameter對象，要知道這個對象的作用，我們得先了解Parameter在ObjectBuilder中所代表的意義，在三種注入模式中，有一個共通的規則，就是需要有參數來注入，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)

第一個參數是參數的類型，第二個參數是參數的名稱，當ConstructorPolicy于SelectConstructor方法時，會依據這兩個參數來選取適合的構造函數，第三個參數是實體對象的類型，以本例來說，就是以PromptDataProcessor這個類型建立對象來傳入需要IDataProcessor類型的構造函數、方法或屬性，第四個參數則影響了DependencyParameter的取值動作，預設情況下，DependencyParameter會先至Locator中取值，這個動作會受到第五個參數：SearchMode的影響(稍后會介紹這一部份)，如果找不到的話，就會依據此參數值來做動作，NotPersentBehavior這個列舉的定義如下：

public enum NotPresentBehavior
{???????????????????
?? CreateNew,
?? ReturnNull,
?? Throw,
}

CreateNew代表著當DependencyParameter于Locator找不到需要的值時，調用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的四個屬性：

DependencyAttribute	DependencyParameter	說明
Name	Name	id(名稱)
CreateType	CreateType	欲建立對象的實體類型
NotPersentBehavior	NotPersentBehavior	當欲建立對象無法由Locator取得時的行為模式。
SearchMode	SearchMode	對Locator的搜尋法則。

使用Dependency Attribute與ConsturctorReflectionStrategy模式的優點是設計者不需花費時間一一建立Parameter對象，而缺點就是CreateType參數，由于ConstructorReflectionStrategy依賴著Dependency Attribute的CreateType參數來決定實際建立對象的類型，這使得設計者必須在標示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的實現對象，一是前面所使用的ConstructorPolicy，二是DefaultCreationPolicy，與ConstructorPolicy不同，DefaultCreationPolicy永遠使用預設的構造函數，如下所示。

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-2、Interface Injection

Interface Injection在ObjectBuidler中可以經由Method Injection來完成，指的是在對象建立后，調用所指定的方法來完成初始化動作，而負責這個工作的就是MethodExecutionStrategy，本節持續延應InputAccept來示范如何于ObjectBuidler中實現Interface Injection。

• MethodExecutionStrategy

要實現Interface Injection，除了必須使用CreationStrategy來建立對象外，還要使用另一個Strategy：MethodExecutionStrategy， 它會在對象建立完成后，執行指定的方法，程序19是使用MethodExecutionStrategy來實現Interface Injection的例子。

程序19

static void UseMethodInfo(MyBuilderContext context)
{
??? context.InnerChain.Add(new CreationStrategy());
??? context.InnerChain.Add(new MethodExecutionStrategy());

??? IMethodCallInfo callInfo = 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());
??? UseMethodInfo(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？

當MethodExecutionStrategy的BuildUp方法被調用時，會透過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-3、Setter 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？

當PropertySetterStrategy的BuildUp方法被調用時，會透過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

相對于ConsturctorReflectionStrategy及MethodReflectionStrategy，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 Attribute及CreateType參數來進行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;
??????? }
??? }
??? ...............
}

轉載于:https://www.cnblogs.com/sw22225458/archive/2008/06/12/1218695.html

總結

以上是生活随笔為你收集整理的Object Builder Application Block (2)的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。