在构建插件式的应用程序框架(二)－－－－订立契约一文中，可以看到我们的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的朋友已经觉得罗唆了，没接触过的还是觉得说得莫明其妙。有空接着写，我会创建几个简单的服务演练演练，增强一下感性认识，呵呵。
我们的插件式的应用程序框架正好也需要这样一个松散的架构，我就移花接木把它应用到我们的框架中。
ServiceContainer是.NET提供的IserviceContainer的实现，如果没有特殊的需要我们不必扩展它，而是直接的利用它。在上一篇文章中我们在实现IApplication接口的时候就直接使用的ServiceContainer。我们在使用Service架构的时候，总是倾向于有一个根容器，各个Service容器构成了一个Service容器树，每一个节点的服务都可以一直向上传递，直到根部，而每一个节点请求Service的时候，我们总是可以从根节点获得。我把这个根节点比喻成一个服务中心，它汇总了所有可提供的服务，当某个对象要请求服务（GetService）只需要向根结点发送要获得的服务，根结点就可以把服务的对象传递给它。
从另外一个角度看，ServiceContainer为我们的插件是应用程序提供了有力的支持，利用ServiceContainer，你不但可以获得应用程序所提供的所有的功能，而且你还可以通过插件向应用程序添加Service，而你添加的Service又可以服务另外的Service，这样我们的应用程序框架就更加的灵活了。但是任何东西都是有两面性的，带来灵活的同时也为开发人员的工作增加了复杂度，所以使用ServcieContianer开发的应用程序必须提供足够详细的文档，否则开发人员可能根本不知道你到底有多少Service可以用，因为很多的Service是通过插件提供的，可能应用程序的作者都不会知道程序发布以后会出现多少Service。
写了这么多，可能接触过ServiceContainer的朋友已经觉得罗唆了，没接触过的还是觉得说得莫明其妙。有空接着写，我会创建几个简单的服务演练演练，增强一下感性认识，呵呵。
