[转] IOC简介
一、IoC 简介
IoC的全名是『Inversion of Control』，字面上的意思是『控制反转』，要了解这个名词的真正含意，得从『控制』这个词切入。一般来说，当设计师撰写一个Console程序时，控制权是在该程序上，它决定着何时该印出讯息、何时又该接受使用者输入、何时该进行数据处理，如程序1。
View Code
using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
namespace Inversion_of_Control
{
class Program
{
static void Main(string[] args)
{
Console.WriteLine("请输入几个单词");
string input = Console.ReadLine();
Console.WriteLine("输入的单词为："+input);
Console.Read();
}
}
}
从整个流程上看来，OS将控制权交给了此程序，接下来就看此程序何时将控制权交回，这是Console模式的标准处理流程。程序1演译了『控制』这个字的意思，那么『反转』这个词的含义呢？这可以用一个Windows Application来演示，如程序2。
View Code
using System;
using System.Collections.Generic;
using System.ComponentModel;
using System.Data;
using System.Drawing;
using System.Linq;
using System.Text;
using System.Windows.Forms;
namespace WindowsFormsApplication1
{
public partial class Form1 : Form
{
public Form1()
{
InitializeComponent();
}
private void button1_Click(object sender, EventArgs e)
{
MessageBox.Show(this.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、为什么我们需要依赖注入？
OK，花了许多篇幅在解释IoC与Dependency Injection两个概念，希望读者们已经明白这两个名词的涵意，在切入Dependency Injection这个主题前，我们要先谈谈为何要使用Dependency Injection，及这样做带来了什么好处，先从程序3的例子开始。
View Code
using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
namespace Inversion_of_Control
{
class Program
{
static void Main(string[] args)
{
InputAccept accept = new InputAccept(new PromptDataProcessor());
accept.Execute();
Console.Read();
}
}
public class InputAccept
{
private IDataProessor _dataProcessor;
//带参的构造方法
public InputAccept(IDataProessor dataProcessor)
{
_dataProcessor = dataProcessor;
}
public void Execute()
{
Console.WriteLine("输入几个单词");
string input = Console.ReadLine();
input = _dataProcessor.ProcessData(input);
Console.WriteLine(input);
}
}
/// <summary>
/// 声明一个接口
/// </summary>
public interface IDataProessor
{
//声明一个返回值为string的传参方法
string ProcessData(string input);
}
public class DummyDataProcessor : IDataProessor
{
//接口中的方法实现
public string ProcessData(string input)
{
return input;
}
}
public class PromptDataProcessor : IDataProessor
{
//接口中的方法实现
public string ProcessData(string input)
{
return "你输入的单词是" + input;
}
}
}
这是一个简单且无用的例子，但却可以告诉我们为何要使用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等样式解决这个问题，如下所示。
View Code
//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，如下所示
View Code
//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的三种模式，请注意！接下来几小节的讨论是依据三种模式的精神，所以例子以简单易懂为主，不考虑本文所提及的完整架构。
-----未完。。。
