传统解耦设计的弊端

为方便描述，举个日志的例子。我简化实现，一个Log类，一个SaveLog方法。如果其他类想拥有记日志功能，那么只需在内部包含一个Log类型的变量：

public class Log   
 {   
      public void SaveLog(string message) {   
         // save log here.   
     }   
 }   
       
 public class ProductService {   
     private Log _log;   
     public ProductService() {   
         _log = newLog();   
     }   
       
     public void SaveProduct() {   
         // save product here.   
         //...   
         _log.SaveLog("save 1 product");   
     }   
 }

有经验的程序员可能会告诉你，这样做会导致其他类与Log耦合。于是，为了解耦，我们将Log类的功能抽象出来，ILog接口就产生了。如此一来，当其他类需要日志功能时，内含变量就从Log变成了ILog：

public interface ILog {   
         void SaveLog(string message);   
     }   
     public class Log:ILog   
     {   
         public void SaveLog(string message)   
         {   
             // save log here.   
         }   
     }   
       
     public class ProductService   
     {   
         private ILog _log;   
         public ProductService()   
         {   
             _log = newLog();   
         }   
         // .......   
  
     }

由于ILog被抽象出来，它的实现类可多样化，保存为txt、xml、数据库，甚至可扩展出邮件通知功能等。基本上，我看到的国内项目里，所谓的解耦就只能走到这一步了，但这种设计真的是所谓的“灵活，易扩展，高内聚，低耦合”吗？

现在，我们来模拟需求变更。假设已有TxtLog类把日志保存成txt文件，但使用一段时间后发现：这种日志难以查询。项目经理决定将日志保存到数据库，DbLog类应运而生。但是由于整个系统充斥着new TxtLog()，转换过程实质上就是逐个查找TxtLog替换成DbLog的过程。此时，项目大小决定出错率，出错导致日志记录不全，记录不全导致系统故障后查不到日志，查不到日志导致找不到原因，找不到原因导致加班，后果太严重了。

忽然有天，高潮降临，经理或老板决定换回txt或换另外一种日志形式，原因不明，或节省成本，或体验不好，或佞臣谗言，或成心玩你，或与数据库有世仇，总之--TMD就是要换。于是，悲剧的查找替换再次上演，几番折腾，千疮百孔。

而此时此刻，你还会称赞这种设计“灵活，易扩展”吗？

迈进IoC大门--改变实例化的方式

现在我们使用Ioc容器--Autofac改进上面的代码，目标是消除代码中的new语句，把实例化类的控制权转移到别的地方，这个地方通常会在一个程序加载时只执行一次的全局方法中。

public class Global {   
     public static IContainer container;   
     public void Application_Start() {   
         ContainerBuilder builder=newContainerBuilder();   
         builder.RegisterType<Log>().As<ILog>();   
         builder.RegisterType<ProductService>();   
         container = builder.Build();   
         var productService = container.Resolve<ProductService>();   
     }   
}   
       
public class ProductService   
{   
     private ILog _log;   
     public ProductService(ILog log)   
     {   
         _log = log;   
     }   
     // .......   
}

上面代码中，ContainerBuilder和IContainer是Autofac中的核心类（之后的文章中会介绍，本文不赘述）。当我们要实例化一个ProductService时，需要写如下代码：

var productService = container.Resolve<ProductService>();

没有任何跟Log有关的操作，但productService中的_log变量确已被赋值了一个Log的实例。Ioc容器会在已注册的组件（类或接口）中匹配实例化参数的类型，一旦发现该类型注册过，则自动将对应的实例赋值给该类型，这个过程叫做--构造函数注入。

回头看看那个曾经折磨过我们的TxtLog换DbLog的问题，托Ioc的福，只要在那个全局方法中改一下类型就解决了。

Ioc不仅仅是控制翻转

也许你会说这个栗子有些极端，实际开发中查找替换的地方并不多，而Ioc只是给实例化换了个地方而已，为了这么一点收益却要付出巨大的学习成本，是否值得？

实际上，Ioc除了控制反转外，还提供了很多对实例生命周期的控制，本文使用的Autofac针对流行的框架(如MVC，WCF)提供了简易整合模块，以及动态代理功能。在不修改原代码的前提下，如何为类中方法添加逻辑？Orchard框架通过Autofac和DynamicProxy库设计出一种很有意思的架构让两个不相干的类的方法逻辑能合并在一起。更多细节，我会在之后的系列文章中向大家展示。