您的位置:首页 > 移动开发 > Objective-C

Object Builder Application Block (2)

2008-06-12 22:27 369 查看

三、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的四个属性:

DependencyAttributeDependencyParameter说明
NameNameid(名称)
CreateTypeCreateType欲建立对象的实体类型
NotPersentBehaviorNotPersentBehavior当欲建立对象无法由Locator取得时的行为模式。
SearchModeSearchMode对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;

}

}

...............

}
内容来自用户分享和网络整理,不保证内容的准确性,如有侵权内容,可联系管理员处理 点击这里给我发消息
标签: