MicroHelper.Net

最近很懒，简直说是无所事事，blogdrive很少更新，博客堂也没有动，一回顾，很多老大最近似乎也是很少出现，神龙见首不见尾呀。

最近考虑以后的职业规划，似乎软件开发提供咨询服务是一个不错的方向，名字嘛，就叫做MicroHelper吧(MicroHelp已经给注册了)

最近IoC很热门，一般翻译为控制反转，也就是一个类将一些工作交给framework（或者控制器）来做。从本质上讲是面向对象的设计原则之一——接口可具体实现的分离的一个具体体现，对象之间解耦的一种方法。

比如说，我们希望设计一个更好用的DropDownList控件，它可以按照如下的方式工作

在这里，我们只关注DataSourceKey这个属性，DataSourceKey是指控件希望根据这个key就可以得到data source，然后自动绑定，那么怎么根据key来得到data source呢，我们需要一个services来完成这件工作

于是我们定义一个接口 IDataSourceProvider

interface IDataSourceProvider
{ ICollection GetDataSource(string key); }

然后有一个类来实现这个接口
class MyDataSourceProvider : IDataSourceProvider
{
 ICollection GetDataSource(string key)
 { ... }
}

class ExDropDownList
{
 IDataSourceProvider myProvider；

 ......
 
 if(AutoBind==true && IsDataBound==false)
 {
  IDataSourceProvider myProvider= (IDataSourceProvider) new MyDataSourceProvider ();
  DataSource = myProvider.GetDataSource(DataSourceKey);
  DataBind();
 }
 
 .............. 
}

这不是一种好的做法，因为这种实现方法大大加强了ExDropDownList和DataSourceProvider之间的依赖关系，在这个例子里，ExDropDownList不仅依赖接口IDataSourceProvider，而且依赖接口的具体实现MyDataSourceProvider，不符合面向对象的原则，如果只是自己项目用问题还不是很大，但是如果别的team也希望用这个控件，但是他们有另外一种提供data source的方法，那么应该怎么办呢。

解耦的办法由很多种，其中一种是把具体创建IDataSourceProvider实例的工作交给容器或者framework来做，也就是说将对IDataSourceProvider的控制反转，有容器决定创建哪一个IDataSourceProvider实例，

接下来，怎么把创建好的IDataSourceProvider实例告诉ExDropDownList呢（或者说注入，Injection）
有三种方法，一种是构造注入，也就是在创建ExDropDownList时就告诉它，哪一个IDataSourceProvider实例可以为你提供GetDataSource的服务

class ExDropDownList
{
 private IDataSourceProvider provider；

 ExDropDownList（IDataSourceProvider  provider）
 {
  this.Provider = provider;
 }
}

另一种方法是设值注入，也就是ExDropDownList对外公布一个方法setProvider或者公布一个属性Provider，让容器可以把创建好的IDataSourceProvider实例传给ExDropDownList。

class ExDropDownList
{
 private IDataSourceProvider provider；

 public Provider
 {
  get{}
  set{}
 }
}

....
ExDropDownList.Provider = (IDataSourceProvider) new MyDataSourceProvider ()
....

第三种是接口注入，也就是说调用者和服务提供者定义一个协议，ExDropDownList如果需要使用DataSourceProvider提供的服务，就需要根据协议实现一个InjectProvider的接口，以便于容器通过这个接口将IDataSourceProvider实例传给ExDropDownList

interface IInjectProvider
{ viod SetProvider(IDataSourceProvider provider ); }

class ExDropDownList : IInjectProvider
{
 SetProvider(IDataSourceProvider provider)
 {
  this.provider = provider;
 }
}

((IInjectProvider)ExDropDownList).SetProvider(IDataSourceProvider) new MyDataSourceProvider ());

接口注入的方法因为对象间还是有很高的耦合度，所以应用不是很广泛。

构造注入和设值注入那一种更好呢。
martin fowler给出了一个解释：
构造注入和设值注入反映了面向对象编程的一个普遍问题，应该在哪里填充对象的字段，是在创建对象时还是通过属性或者方法来设定值。martin fowler建议在对象构造时就创建完正合法的对象，这样做还有一个好处就是可以隐藏不可改变的字段（注：或者不应该在运行期间随意改变的字段），而公布一个设置方法，就意味着调用者可以自由改变字段的值。

凡事总有例外，如果参数太多，构造注入使系统显得有点凌乱，而且有些时候没有办法使用构造注入，比如上面ExDropDownList 的例子，创建ExDropDownList 实例不是我们的framework能够控制的。需要设值注入来协助。

我们怎么做的呢？把ExDropDownList的provider定义为静态属性，然后在Application_BeginRequest事件赋值
DataSourceProvider provider = new DataSourceProvider();
ExDropDownList.dataSourceProvider = provider;

这属于代码配置

用ExDropDownList 的例子来说明IoC不太恰当，因为ExDropDownList不是我们的framework能够完全控制的。除了IoC这种解耦方法外还有别的方法比如在config文件定义哪一个Assembly可以提供GetDataSource服务，或者我们定义一个ServicesFind类，它知道怎么样可以得到我们所需的IDataSourceProvider实例。

IoC现在看来，主要是用来解决接口参数的注入。framework可以根据很简单的约定，将不同组件组装起来，IoC不是新的事物，也不是哪一种语言的特有功能，只是一种组件的协作和组织方式。

Microhlper.HOWTPPSE.V010

打印 | 张贴于 2004-06-24 13:44:00 | Tag:拥抱变化