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());
}
} 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 > 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()); }} < components > < component id ="NotifyModule" service ="TestProject.NotifyModule, TestProject" type ="TestProject.NotifyModule, TestProject" /> </ components >