昨天看了Idior的文章EnterLib ObjectBuild vs Castle WindsorContainer, part 1，联想到我前面刚交付的一个系统，感触颇为深刻。在我那个系统的业务层只暴露了六个关键的接口，这些接口用于处理一些核心的运算：
>>实现运行时的URL计算；
>>在网格中打开相应的实体类；
>>在实体类中显示到网格中的属性转换器；
>>在编辑器中使用相应的属性编辑器。
实现这些接口，一共用了接近1000个内部类，有些类的实现甚至只需要一行代码(例如从某个类派生但需要覆写某一个方法以便更换约束子)。
为了管理这些实现类，我建立了一个专门的枚举，这个枚举包括近100个项，囊括了整个业务层涉及到的所有层面。然后定义一个ServiceMasterAttribute的标签，将这些类列到每个枚举项上。在这个标签的静态构造器中，找到所有枚举项的所有实现类，并通过专门的类进行管理，再通过Service类封装这个管理器，得到一个简单的API：
|
public static object Service.GetObject(TargetType targetType, Type expectType)
|
只需要将这个枚举的定义与所有的实现类放在同一个程序集中，就完全可以将这些实现类隐藏起来。可以看出来，这种方式简单而有效。
另外一个同事，负责整个系统的报表，采用一个自定义的控件来实现数据到HtmlTable的变换。在这个变换过程中，定义了一个接口，用于填充单元格的数据。在实现这个接口的过程中，根据项目实际又组织了六个内部接口，通过70多个类来实现这些接口，然后由这些接口通过专门的类来组织单元格填充接口。因为系统业务层提供了一种非常方便的配置文件访问方式，所以他采用配置文件来定位这些类，结果就冒出来一种很奇怪的现象：具体实现类必须public修饰以便配置文件管理可以拿到这些类型；而接口只是用来在内部以适配器方式接入单元格填充接口，反而只需要internal修饰。
所以，采用标签方式所获得的IoC具有通过配置文件所不具备的两大优势：
>>运行时类型检查，设计时就可以避免拼写错误这些低级的错误；
>>完全隐藏实现细节，只需要将接口暴露出来
标签方式也存在一个缺点：不能通过修改配置来修改实现类，而必须重新编译。
所以，如果你真的需要在运行时修改配置而不用重新编译的话，就必须采用配置方式来定位类的实现。