构建插件式的应用程序框架(四)－－－－服务容器(ZT)

在 构建插件式的应用程序框架(二)－－－－订立契约 一文中，可以看到我们的 IApplication 接口是派生于 IServiceContainer 接口的。为什么要派生于 IServiceContainer 呢？我们来看看 IServiceContainer 的定义，它有几个 AddService 方法和 RemoveService 方法以及从 IserviceProvider 继承过来的 GetService 方法。 Service 本身是 .NET 设计时架构的基础， Service 提供设计时对象访问某项功能的方法实现，说起来还真拗口。就我看来， ServiceContainer 机制的本质就是解耦合，就是将类型的设计时功能从类型本身剥离出来。如果你把类型的设计时功能也封装到类型里，这样的类型包含了很多只有开发人员才会用到而最终用户根本不需要的功能，使得类型既臃肿有不便于扩展。而将设计时功能剥离出来，这样类型就可以不依赖于特定的设计环境，之所以现在有这么多非官方的 .NET 设计环境可能就是这个原因吧。
       我们的插件式的应用程序框架正好也需要这样一个松散的架构，我就移花接木把它应用到我们的框架中。
       ServiceContainer 是 .NET 提供的 IserviceContainer 的实现，如果没有特殊的需要我们不必扩展它，而是直接的利用它。在上一篇文章中我们在实现 IApplication 接口的时候就直接使用的 ServiceContainer 。我们在使用 Service 架构的时候，总是倾向于有一个根容器，各个 Service 容器构成了一个 Service 容器树，每一个节点的服务都可以一直向上传递，直到根部，而每一个节点请求 Service 的时候，我们总是可以从根节点获得。我把这个根节点比喻成一个服务中心，它汇总了所有可提供的服务，当某个对象要请求服务（ GetService ）只需要向根结点发送要获得的服务，根结点就可以把服务的对象传递给它。
       从另外一个角度看， ServiceContainer 为我们的插件是应用程序提供了有力的支持，利用 ServiceContainer ，你不但可以获得应用程序所提供的所有的功能，而且你还可以通过插件向应用程序添加 Service ，而你添加的 Service 又可以服务另外的 Service ，这样我们的应用程序框架就更加的灵活了。但是任何东西都是有两面性的，带来灵活的同时也为开发人员的工作增加了复杂度，所以使用 ServcieContianer 开发的应用程序必须提供足够详细的文档，否则开发人员可能根本不知道你到底有多少 Service 可以用，因为很多的 Service 是通过插件提供的，可能应用程序的作者都不会知道程序发布以后会出现多少 Service 。
       写了这么多，可能接触过 ServiceContainer 的朋友已经觉得罗唆了，没接触过的还是觉得说得莫明其妙。有空接着写，我会创建几个简单的服务演练演练，增强一下感性认识，呵呵。