雨中的阳光Seattle

靠着很近的Redmond

[转][黄忠成]Object Builder Application Block (1) 2007年09月10日

Filed under: C#,dotNet,IoC,Object Builder — systembug @ 3:02 上午

本文相关代码下载

[转]Object Builder Application Block

文/黄忠成 ;2006/9/21

原文链接:http://blog.csdn.net/Code6421/archive/2006/09/25/1282139.aspx

整理:吕震宇

一、IoC 简介

IoC的全名是『Inversion of Control』,字面上的意思是『控制反转』,要了解这个名词的真正含意,得从『控制』这个词切入。一般来说,当设计师撰写一个Console程序时,控制权是在该程序上,它决定着何时该印出讯息、何时又该接受使用者输入、何时该进行数据处理,如程序1。

程序1

using System;
using System.Collections.Generic;
using System.Text;
namespace ConsoleApplication2
{
class Program
    {
static void Main(string[] args)
        {
            Console.Write(“Please Input Some Words:”);
string inputData = Console.ReadLine();
            Console.WriteLine(inputData);
            Console.Read();
        }
    }
}

从整个流程上看来,OS将控制权交给了此程序,接下来就看此程序何时将控制权交回,这是Console模式的标准处理流程。程序1演译了『控制』这个字的意思,那么『反转』这个词的含义呢?这可以用一个Windows Application来演示,如程序2。

程序2

using System;
using System.Collections.Generic;
using System.ComponentModel;
using System.Data;
using System.Drawing;
using System.Text;
using System.Windows.Forms;
namespace WindowsApplication10
{
public partial class Form1 : Form
    {
public Form1()
        {
            InitializeComponent();
        }
private void button1_Click(object sender, EventArgs e)
        {
            MessageBox.Show(textBox1.Text);
        }
    }
}

与程序1不同,当程序2被执行后,控制权其实并不在此程序中,而是在底层的Windows Forms Framework上,当此程序执行后,控制权会在Application.Run函数调用后,由主程序转移到Windows Forms Framework上,进入等待讯息的状态,当用户按下了Form上的按钮后,底层的Windows Forms Framework会收到一个讯息,接着会依照讯息来 调用button1_Click方法,此时控制权就由Windows Forms Framework转移到了主程序。程序2充份演译了『控制反转』的意含,也就是将原本位于主程序中的控制权,反转到了Windows Forms Framework上。

二、Dependency Injection

IoC的中心思想在于控制权的反转,这个概念于现今的Framework中相当常见,.NET Framework中就有许多这样的例子,问题是!既然这个概念已经 实现于许多Framework中,那为何近年来IoC会于社群引起这么多的讨论?著名的IoC实现对象如Avalon、Spring又达到了什么目的呢?就笔者的认知,IoC是一个广泛的概念,主要中心思想就在于控制权的反转,Windows Forms Framework与Spring在IoC的大概念下,都可以算是IoC的实现对象,两者不同之处在于究竟反转了那一部份的控制权,Windows Forms Framework将主程序的控制权反转到了自身上,Spring则是将对象的建立、释放、配置等控制权反转到自身,虽然两者都符合IoC的大概念,但设计初衷及欲达成的目的完全不同,因此用IoC来统称两者,就显得有些笼统及模糊。设计大师Martin Fowler针对Spring这类型IoC实现对象提出了一个新的名词『Dependency Injection』,字面上的意思是『依赖注入』。对笔者而言,这个名词比起IoC更能描述现今许多宣称支持IoC的Framework内部的行为,在Martin Fowler的解释中, Dependency Injection分成三种,一是Interface Injection(接口注射)、Constructor Injection(构造函数注射)、Setter Injection(设值注射)。

2-1、Why we need Dependency Injection?

OK,花了许多篇幅在解释IoC与Dependency Injection两个概念,希望读者们已经明白这两个名词的涵意,在切入Dependency Injection这个主题前,我们要先谈谈为何要使用Dependency Injection,及这样做带来了什么好处,先从程序3的例子开始。

程序3

using System;
using System.Collections.Generic;
using System.Text;
namespace DISimple
{
class Program
    {
static void Main(string[] args)
        {
            InputAccept accept = new InputAccept(new PromptDataProcessor());
            accept.Execute();
            Console.ReadLine();
        }
    }
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
    }
}

这是一个简单且无用的例子,但却可以告诉我们为何要使用Dependency Injection,在这个例子中,必须在建立InputAccept对象时传入一 个实现IDataProcessor接口的对象,这是Interface Base Programming概念的设计模式,这样做的目的是为了降低InputAccept与实现对象间的耦合关系,重用InputAccept的执行流程,以此来增加程序的延展性。那这个设计有何不当之处呢?没有!问题不在InputAccept、IDataProcessor的设计,而在于使用的方式。

InputAccept accept = new InputAccept(new PromptDataProcessor());

使用InputAccept时,必须在建立对象时传入一个实现IDataProcess接口的对象,此处直接建立一个PromptDataProcessor对象传入,这使得主程序与PromptDataProcessor对象产生了关联性,间接的摧毁使用IDataProcessor时所带来的低耦合性,那要如何解决这个问题呢?读过Design Patterns的读者会提出以Builder、Factory等样式解决这个问题,如下所示。

//Factory
InputAccept accept = new InputAccept(DataProcessorFactory.Create());
//Builder
InputAccept accept = new InputAccept(DataProcessorBulder.Build());

两者的实际流程大致相同,DataProcessorFactory.Create方法会依据组态档的设定来建立指定的IDataProcessor实现对象,回传后指定给InputAccept,DataProcessBuilder.Build方法所做的事也大致相同。这样的设计是将原本位于主程序中IDataProcessor对象的建立动作,转移到DataProcessorFactory、DataProcessorBuilder上,这也算是一种IoC观念的实现,只是这种转移同时也将主程序与IDataProcessor对象间的关联,平移成主程序与DataProcessorFactory间的关联,当需要建立的对象一多时,问题又将回到原点,程序中一定会充斥着AFactory、BFactory等Factory对象。彻底将关联性降到最低的方法很简单,就是设计Factory的Factory、或是Builder的Builder,如下所示。

//declare
public class DataProcessorFactory : IFactory
……….
//Builder
public class DataProcessorBuilder : IBuilder
………..
………………..
//initialize
//Factory 
GenericFactory.RegisterTypeFactory(typeof(IDataProcessor),typeof(DataProcessorFactory));
//Builder
GenericFactory.RegisterTypeBuilder(typeof(IDataProcessor),typeof(DataProcessorBuilder));
…………….
//Factory
InputAccept accept = new InputAccept(GenericFactory.Create(typeof(IDataProcessor));
//Builder
InputAccept accept = new InputAccept(GenericBuilder.Build(typeof(IDataProcessor));

这个例子中,利用了一个GenericFactory对象来建立InputAccept所需的IDataProcessor对象,当GenericFactory.Create方法被 调用时,它会查询所拥有的Factory对象对应表,这个对应表是以type of base class/type of factory成对的格式存放,程序必须在一启动时准备好这个对应表,这可以透过组态档或是程序代码来完成,GenericFactory.Create方法在找到所传入的type of base class所对应的type of factory后,就建立该Factory的实体,然后调用该Factory对象的Create方法来建立IDataProcessor对象实体后回传。另外,为了统一Factory的 调用方式,GenericFactory要求所有注册的Factory对象必须实现IFactory接口,此接口只有一个需要实现的方法:Create。方便读者易于理解这个设计概念,图1以流程图呈现这个设计的。

图1

那这样的设计有何优势?很明显的,这个设计已经将主程序与DataProcessorFactory关联切除,转移成主程序与GenericFactory的关联,由于只使用一个Factory:GenericFactory,所以不存在于AFactory、BFactory这类问题。这样的设计概念确实降低了对象间的关联性,但仍然不够完善,因为有时对象的构造函数会需要一个以上的参数,但GenericFactory却未提供途径来传入这些参数(想象当InputAccept也是经由GenericFactory建立时),当然!我们可以运用object[]、params等途径来传入这些参数,只是这么做的后果是,主程序会与实体对象的构造函数产生关联,也就是间接的与实体对象产生关联。要切断这层关联,我们可以让GenericFactory自动完成InputAccept与IDataProcessor实体对象间的关联,也就是说在GenericFactory中,依据InputAccept的构造 函数声明,取得参数类型,然后使用该参数类型(此例就是IDataProcessor)来调用GenericFactory.Create方法建立实体的对象,再将这个对象传给InputAccept的构造函数,这样主程序就不会与InputAccept的构造函数产生关联,这就是Constructor Injection(构造函数注入)的概念。以上的讨论,我们可以理出几个重点,一、Dependency Injection是用来降低主程序与对象间的关联,二、Dependency Injection同时也能降低对象间的互联性,三、Dependency Injection可以简化对象的建立动作,进而让对象更容易使用,试想!只要调用GenericFactory.Create(typeof(InputAccept))跟原先的设计,那个更容易使用?不过要拥有这些优点,我们得先拥有着一个完善的架构,这就是ObjectBuilder、Spring、Avalon等Framework出现的原因。

PS:这一小节进度超前许多,接下来将回归Dependency Injection的三种模式,请注意!接下来几小节的讨论是依据三种模式的精神,所以例子以简单易懂为主,不考虑本文所提及的完整架构。

2-2、Interface Injection

Interface Injection指的是将原本建构于对象间的依赖关系,转移到一个接口上,程序4是一个简单的例子。

程序4

using System;
using System.Collections.Generic;
using System.Text;
namespace ConsoleApplication2
{
class Program
    {
static void Main(string[] args)
        {
            InputAccept accept = new InputAccept();
            accept.Inject(new DummyDataProcessor());
            accept.Execute();
            Console.Read();
        }
    }
public class InputAccept
    {
private IDataProcessor _dataProcessor;
public void Inject(IDataProcessor dataProcessor)
        {
            _dataProcessor = dataProcessor;
        }
public void Execute()
        {
            Console.Write(“Please Input some words:”);
string input = Console.ReadLine();
            input = _dataProcessor.ProcessData(input);
            Console.WriteLine(input);
        }
    }
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
    }
}

InputAccept对象将一部份的动作转移到另一个对象上,虽说如此,但InputAccept与该对象并未建立依赖关系,而是将依赖关系建立在一个接口:IDataProcessor上,经由一个方法传入实体对象,我们将这种应用称为Interface Injection。当然,如你所见,程序4的手法在实务应用上并未带来太多的好处,原因是执行Interface Injection动作的仍然是主程序,这意味着与主程序与该对象间的依赖关系仍然存在,要将Interface Injection的概念发挥到极致的方式有两个,一是使用组态文件,让主程序由组态文件中读入DummaryDataProcessor或是PromptDataProcessor,这样一来,主程序便可以在不重新编译的情况下,改变InputAccept对象的行为。二是使用Container(容器),Avalon是一个标准的范例。

程序5

public class InputAccept implements Serviceable {
private IDataProcessor m_dataProcessor;
public void service(ServiceManager sm) throws ServiceException {
      m_dataProcessor = (IDataProcessor) sm.lookup(“DataProcessor”);
 }
public void Execute() {
    ……..
string input = m_dataProcessor.ProcessData(input);
    ……..
 }
}

在Avalon的模式中,ServiceManager扮演着一个容器,设计者可以透过程序或组态文件,将特定的对象,如DummyDataProcessor推到容器中,接下来InputAccept就只需要询问容器来取得对象即可,在这种模式下,InputAccept不需再撰写Inject方法,主程序也可以藉由ServiceManager,解开与DummyDataProcessor的依赖关系。使用Container时有一个特质,就是Injection动作是由Conatiner来自动完成的,这是Dependency Injection的重点之一。

PS:在正确的Interface Injection定义中,组装InputAccept与IDataProcessor的是容器,在本例中,我并未使用容器,而是提取其行为。

2-3、Constructor Injection

Constructor Injection意指构造函数注入,主要是利用构造函数参数来注入依赖关系,构造函数注入通常是与容器紧密相关的,容器允许设计者透过特定方法,将欲注入的对象事先放入容器中,当使用端要求一个支持构造函数注入的对象时,容器中会依据目标对象的构造函数参数,一一将已放入容器中的对象注入。程序6是一个简单的容器类别,其支持Constructor Injection。

程序6

public static class Container
{
private static Dictionary<Type, object> _stores = null;
private static Dictionary<Type, object> Stores
    {
get
        {
if (_stores == null)
                _stores = new Dictionary<Type, object>();
return _stores;
        }
    }
private static Dictionary<string, object> CreateConstructorParameter(Type targetType)
    {
        Dictionary<string, object> paramArray = new Dictionary<string, object>();
        ConstructorInfo[] cis = targetType.GetConstructors();
if (cis.Length > 1)
throw new Exception(“target object has more then one constructor,container can’t peek one for you.”);
foreach (ParameterInfo pi in cis[0].GetParameters())
        {
if (Stores.ContainsKey(pi.ParameterType))
                paramArray.Add(pi.Name, GetInstance(pi.ParameterType));
        }
return paramArray;
    }
public static object GetInstance(Type t)
    {
if (Stores.ContainsKey(t))
        {
            ConstructorInfo[] cis = t.GetConstructors();
if (cis.Length != 0)
            {
                Dictionary<string, object> paramArray = CreateConstructorParameter(t);
                List<object> cArray = new List<object>();
foreach (ParameterInfo pi in cis[0].GetParameters())
                {
if (paramArray.ContainsKey(pi.Name))
                        cArray.Add(paramArray[pi.Name]);
else
                        cArray.Add(null);
                }
return cis[0].Invoke(cArray.ToArray());
            }
else if (Stores[t] != null)
return Stores[t];
else
return Activator.CreateInstance(t, false);
        }
return Activator.CreateInstance(t, false);
    }
public static void RegisterImplement(Type t, object impl)
    {
if (Stores.ContainsKey(t))
            Stores[t] = impl;
else
            Stores.Add(t, impl);
    }
public static void RegisterImplement(Type t)
    {
if (!Stores.ContainsKey(t))
            Stores.Add(t, null);
    }
}

Container类别提供了两个方法,RegisterImplement有两个重载方法,一接受一个Type对象及一个不具型物件,它会将传入的Type及对象成对的放入Stores这个Collection中,另一个重载方法则只接受一个Type对象,调用这个方法代表调用端不预先建立该对象,交由GetInstance方法来建立。GetInstance方法负责建立对象,当要求的对象类型存在于Stores记录中时,其会取得该类型的构造函数,并依据构造函数的参数,一一调用GetInstance方法来建立对象。程序7是使用这个Container的范例。

程序7

class Program
{
static void Main(string[] args)
    {
        Container.RegisterImplement(typeof(InputAccept));
        Container.RegisterImplement(typeof(IDataProcessor), new PromptDataProcessor());
        InputAccept accept = (InputAccept)Container.GetInstance(typeof(InputAccept));
        accept.Execute();
        Console.Read();
    }
}
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
}

2-4、Setter Injection

Setter Injection意指设值注入,主要概念是透过属性的途径,将依赖对象注入目标对象中,与Constructor Injection模式一样,这个模式同样需要容器的支持,程序8是支持Setter Injection的Container程序行表。

程序8

public static class Container
{
private static Dictionary<Type, object> _stores = null;
private static Dictionary<Type, object> Stores
    {
get
        {
if (_stores == null)
                _stores = new Dictionary<Type, object>();
return _stores;
        }
    }
public static object GetInstance(Type t)
    {
if (Stores.ContainsKey(t))
        {
if (Stores[t] == null)
            {
object target = Activator.CreateInstance(t, false);
foreach (PropertyDescriptor pd in TypeDescriptor.GetProperties(target))
                {
if (Stores.ContainsKey(pd.PropertyType))
                        pd.SetValue(target, GetInstance(pd.PropertyType));
                }
return target;
            }
else
return Stores[t];
        }
return Activator.CreateInstance(t, false);
    }
public static void RegisterImplement(Type t, object impl)
    {
if (Stores.ContainsKey(t))
            Stores[t] = impl;
else
            Stores.Add(t, impl);
    }
public static void RegisterImplement(Type t)
    {
if (!Stores.ContainsKey(t))
            Stores.Add(t, null);
    }
}

程序代码与Constructor Injection模式大致相同,两者差异之处仅在于Constructor Injection是使用构造函数来注入,Setter Injection是使用属性来注入,程序9是使用此Container的范例。

程序9

class Program
{
static void Main(string[] args)
    {
        Container.RegisterImplement(typeof(InputAccept));
        Container.RegisterImplement(typeof(IDataProcessor), new PromptDataProcessor());
        InputAccept accept = (InputAccept)Container.GetInstance(typeof(InputAccept));
        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);
    }
}

2-5、Service Locator

在Martain Fowler的文章中,Dependency Injection并不是唯一可以将对象依赖关系降低的方式,另一种Service Locator架构也可以达到同样的效果,从架构角度来看,Service Locator是一个服务中心,设计者预先将Servcie对象推入Locator容器中,在这个容器内,Service是以Key/Value方式存在。欲使用该Service对象的对象,必须将依赖关系建立在Service Locator上,也就是说,不是透过构造函数、属性、或是方法来取得依赖对象,而是透过Service Locator来取得。

Advertisements
 

发表评论

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / 更改 )

Twitter picture

You are commenting using your Twitter account. Log Out / 更改 )

Facebook photo

You are commenting using your Facebook account. Log Out / 更改 )

Google+ photo

You are commenting using your Google+ account. Log Out / 更改 )

Connecting to %s