Ioc容器应用浅析--EasyJF学习

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

public class Email

public interface IEmailSender

public class SimonwEmailSender : IEmailSender

public class EmailSenderFactory

public class CommonService

<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

<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/