Ioc容器应用浅析
Ioc(Inversion of Control)中文译名控制反转, 一个很流行的词汇, 虽然dotNet社群谈论的仍然比较少, 但随着dotNet平台下的一些Ioc组件的成熟, 这个概念也慢慢深入人心了, 本文并不抓住概念大谈特谈, 而是从一个简单的示例以平实的语言和大多开发者所遇到的问题来简单分析下Ioc容器能为我们带来什么及如何更好使用.
Ioc(控制反转)是一个目标, 他要求我们设计好的类不由我们自己控制而由系统控制, 这样可以使系统变得更加独立, 从而强壮易于扩展维护, 实现这个目标有一些手段如DI(Dependency Injection), Service Locator等, 但这对于用户并不重要, 我们关键要的是这个目标. 而Ioc容器正是帮助我们实现这一目标的组件. 一般他们都使用了DI做为实现手段. 概念就谈到这里为止, 太多了容易让人头晕.
dotNet下的Ioc容器也有不少了, 下面以Castle Ioc容器为例说明, 代码为了清晰起见省略了很多东西仅仅起示例作用并不代表实际如此.
面临的问题
需求是这样的(以下情节纯属虚构, 如有雷同纯属巧合), 项目需要一个向用户发送email做为提醒的功能, 因此项目中包含一个NotifyModule的类用来做提醒功能, 而真正的email发送功能使用的是我开发的很烂的一个称为第三方组件的SimonwEmailSender完成(后来领导发现了我写的果然很烂于是决定 使用MSEmailSender), SimonwEmailSender是标准服务接口IEmailSender实现. 下面的注释中标识了4中不同的email组件的调用方法.
public class NotifyModule
{
//1. SimonwEmailSender sender = new SimonwEmailSender(); //2. IEmailSender sender = new SimonwEmailSender(); //3. IEmailSender sender = EmailSenderFactory.Create(); //4. IEmailSender sender = CommonService.Container.Resolve<IEmailSender>(); public void SendMessage()
{
//create your email then send sender.Send(new Email(
));
}
}下面是支持NotifyModule的其他类代码
public class Email { private string receiver; private string message; // } public interface IEmailSender { void Send(Email mail); } public class SimonwEmailSender : IEmailSender { public void Send(Email mail) { //implement IEmailSender.Send } } public class EmailSenderFactory { public static IEmailSender Create() { //1. return new SimonwEmailSender(); //2. return Activator.CreateInstance(), use Reflection create IEmailSender from config file or assembly } } public class CommonService { public static readonly IWindsorContainer Container; static CommonService() { //1. Container.AddComponent("", typeof(IEmailSender), typeof(SimonwEmailSender)); //2. Container = new WindsorContainer(new XmlInterprete } }获取组件的方式
下面分别来分析下NotifyModule中的4中不同的获取组件的方式.
第一种, SimonwEmailSender sender = new SimonwEmailSender();
这样个方式非常直观, 但造成了项目对外部组件的依赖,
更为严重的是项目中或许会有人使用仅仅属于SimonwEmailSender的方法而并非只是IEmailSender定义的标准服务,
当项目需要更换组件的时候不对代码大动干戈是不可能了. 因此每当你写下这样一行代码你就要仔细考虑清楚未来是否会变更,
如果预计到会改变一定不要这样写, 会给未来的扩展和维护带来无穷的后患.
第二种, IEmailSender sender = new SimonwEmailSender();
既然这是一个变动很大的组件, 为了限定用户程序员可能不规范的使用, 采用标准服务接口IEmailSender 来声明对象,
这样用户就没法去调用只属于SimonwEmailSender自己特有的方法了, 更换组件的时候省心不少. 但更改代码仍然无法避免,
实例化的时候使用了具体的组件类. 相信这也是不少初学OO的朋友所遇到的问题, 接口不是消除了依赖了么? 但依赖变化的时候还要改代码,
依然没什么优势嘛. 于是引出了下一种方式.
第三种, IEmailSender sender = EmailSenderFactory.Create();
工厂, 在Ioc容器出现以前被广泛应用于各种项目中, 甚至有这样的说法, 没有工厂的项目就不是好项目, 虽然有点偏激但却有一定道理.
以EmailSenderFactory.Create()来推迟了组件的实例化, 这样看起来无论声明和实例化都脱离了对具体组件的依赖,
但具体的组件终究还是要实例化, 在哪里呢? 看看工厂的实现, 在EmailSenderFactory.Create()中有2中实现方案.
方案一中直接return new SimonwEmailSender(); 这效果和上一种方式没啥本质区别了, 到头来换了组件还得修改代码.
再看方案二, 读取配置文件中的信息, 用反射来实例化组件, 彻底的把具体组件的信息从代码中剥离到了配置文件中, 更换组件时仅需要修改配置文件.
接口终于完全的发挥出了他的威力, 但这种方式造成大量不统一的工厂产生, 而组件之间常会有着各种不同的依赖关系, 使得工厂的复杂度大大增加,
实现与管理这些工厂又成了新的问题, Ioc容器就在这样的需求下出现了.
第四种, IEmailSender sender = CommonService.Container.Resolve<IEmailSender>();
看起来和通过工厂获取实例差不多, 但却不是同一个东西, CommonService.Container即是我简易包装的一个Castle
Ioc容器, 具体的使用下面会详细介绍, 现在你只需要知道我从容器中来获取组件的实例. Ioc容器是一个可复用的组件管理工具,
可以很方便的引入到项目中, 通过向其中简单的注册需要被管理的组件后, 他便能管理组件和他们之间的关系. 这样避免了大量的工厂出现,
更进一步的减少了代码量, 提高了项目的扩展维护性.
使用Ioc容器
Ioc容器负责组件对象管理, 因此使用时包括两个步骤, 在容器中注册组件与从容器中取出组件. 其方法也根据具体项目的不同需求而不同.
组件注册
组件注册就是把组件放入到容器中以便容器管理, 具体方法主要是硬编码注册和配置文件注册.参见类CommonService, Container是对容器的引用, 在构造函数中有2种注册方式.
第一种, 硬编码注册方式, Container.AddComponent("MailCom", typeof(IEmailSender), typeof(SimonwEmailSender));
存在的问题还是那样, 使项目对具体的组件造成了直接依赖, 因为这里直接引用了SimonwEmailSender类型,
Ioc容器的优势没有完全发挥出来. 但这样也有这样的优点, 注册过程非常简便, 虽然更换组件需要修改代码但修改的地方非常集中,
因此对于一些规模小或组件繁多且不易变更的项目很有优势.
第二种, 配置文件方式, Container = new WindsorContainer(new XmlInterpreter());
XmlInterpreter使用默认的App.Config文件中的组件配置来实例化容器, 他会自动解释xml配置文件将组件注册入容器.
当然你可以也自定义组件配置格式或指定xml配置文件. 这个方式最为灵活, 你可以方便的修改更换组件, 但配置就较麻烦了,
尤其组件很多的情况下, 而且无法在编译时发现错误, 只能在运行时发现, 调试起来比较困难.
<components> <component id="MailCom" service="TestProject.IEmailSender, TestProject" type="TestProject.SimonwEmailSender, TestProject" /></components>组件配置节点中service需要指明接口类型和所在程序集, type中需要指明具体组件类型和所在程序集, id指索引的名称, 这是一个信息完整的配置节点, 容器可以完全通过这些信息实例化组件因此只需Container = new WindsorContainer(new XmlInterpreter());一句话就能完成注册工作. 这时的项目已经完全脱离了对具体组件的依赖, 你在代码中看不到任何具体组件的影子.
获取组件
注册完成后我们关心该如何拿到这些组件并使用他们. Ioc容器同样提供了2种方式, 从容器中直接取出与通过容器的注入方式装配.
第一种, 从容器中直接获取, IEmailSender sender = CommonService.Container.Resolve<IEmailSender>();
这就是NotifyModule中第四种方式, 通过以上的注册后你可以直接从容其中得到服务的实例. 不过你发现了么, 虽然解除了对组件的依赖, 但现在开始对容器依赖了, 即便容器是个独立可复用的组件, 这种方式一多也会让人很不爽, 起码不优雅. 容器不是能管理组件么, 利用这个特性可以大大简化代码.
第二种, 注入, 我修改了NotifyModule类, 代码如下
public class NotifyModule{ private IEmailSender sender; //Inject method 1 public NotifyModule(IEmailSender sender) { this.sender = sender; } //Inject method 2 public IEmailSender EmailSender { set { this.sender = value; } } public void SendMessage() { //create your email then send sender.Send(new Email()); }}并在配置文件中加入以下配置注册NotifyModule到容器中
<components> <component id="NotifyModule" service="TestProject.NotifyModule, TestProject" type="TestProject.NotifyModule, TestProject" /></components>所谓注入就是你不用亲自去实例化你的对象(例如上面那个从容器中获得实例的例子)而由容器去为你完成. 享受这强大功能的前提是所有组件必须纳入容器内.现在NotifyModule也纳入了容器的管理, 你只需要为你的类设置一个接收器, 然后里面就可以肆意的去使用了根本不用操心他的实例化问题. 新修改的NotifyModule类中有2种注入组件的方法也就是接收器分别标记了Inject method 1 通过构造函数注入 和 Inject method 2 通过属性注入他们不需要同时存在, 只代表了2种不同的注入方式.
通过构造函数注入, 非常清晰, 使你一眼就能看到你的类中在使用那些组件, 我个人偏向这种方式. 但有时候构造的参数较多, 并且有的参数可选时, 使用属性注入方式更好些. 属性注入方式可以更好的保留类业务逻辑的本意, 不会在构造时加入那些不需要业务逻辑关心的参数. 总之各有各的好处, 灵活处理吧. 通过透明的注入方式最大程度的减少了项目对容器的依赖, 若要完全摆脱这样的依赖依然需要使用容器的服务接口通过反射来实例化容器, 不过我认为大多数情况下这么做没什么必要.
最后
最后需要说几点, Ioc容器要根据实际情况来使用, 并不是所有的对象都要纳入Ioc容器管理, 直接声明的方式不是绝对不好,如 SimonwEmailSender sender = new SimonwEmailSender(); 当你确定对象是不发生改变的这样是最优的声明方式, 体现了内聚性, 就好似脑袋和身体间不需要接口. 当然还有不少东西没有讨论, 如依赖检查, 自动装配, 接口注入等等, 但我认为通过这个文档你已经有了个较清晰的概观, 接下来就可以研究概念了. 如需更多技术细节请参阅Terrylee的Castle系列文章.
Simonw 2006.10.6 / Msn: i-simon@msn.com
如有转载请注明出自博客园, 原文地址：http://simonw.cnblogs.com/
