【目录】-【模块化和插件化】-【小结】
现在我们来对OSGi.NET的“模块化和插件化”做一个小结，再次把官方的说明拿出来
1） 物理隔离：基于UIOSP开发的模块是一个物理隔离的可单独部署的模块，每一个模块拥有独立的文件夹、类型空间、资源和类加载器。模块间互相独立、互相隔离且互不影响。
a) 先看看上面实例目录结构
b) 很明显的看出，三个模块的确是被“隔离“在三个不同的文件夹内，且Calculator.Demo1和RemotingManagement、WebServiceWrapperService无依赖，即前者无法知道后两者是否存在，也不需要知道，他们相互不影响。因为我们将Calculator.Demo1放入Plugins目录之前或之后，对于其他两个模块来说，没有什么不同，没有影响他们的功能和作用。同样，我们将RemotingManagement、WebServiceWrapperService移出Plugins目录后，也不会对Calculator.Demo1有影响。
c) 但RemotingManagement和WebServiceWrapperService是相互依赖的，WebServiceWrapperService作为一个Web Service包装器向RemotingManagement提供服务，所以RemotingManagement要依赖WebServiceWrapperService。当移掉WebServiceWrapperService之后，RemotingManagement就无法正常启动，OSGi.NET会抛出异常并记录在log.txt中。
为了验证OSGi.NET的这个“依赖解析”功能，我们将WebServiceWrapperService移出Plugins目录。照常按F5启动程序，界面上你是看不到任何变化，但这时再打开“远程管理工具”，就提示“无法连接到远程服务器”了。
同时，在log.txt中会出现依赖解析异常信息
2） 高度可重用：模块的重用不需要再更改任何代码，只需要将模块拷贝到UIOSP指定的插件目录下，它的功能便向其它模块暴露。
a) RemotingManagement和WebServiceWrapperService就是最好的例子，几乎模板中每个主应用程序都包含这两个模块，且都是一样的。
b) 这应该是OSGi模块化最“神奇”的地方吧，想像一下，将两个文件夹放入主程序中，他的功能就增加了，移除了就减少了，对主程序和其他模块没有任何“物理伤害”！
3） 规范化：模块具有统一的标准，每一个模块的目录结构、模块配置都是统一的，开发方法也完全一致。
a) Plugins里的三个模块几乎相同，Manifest.xml，程序集或以来程序及和资源文件等。
4） 快速集成：仅需要将模块都拷贝到指定的插件目录就能够实现模块功能的快速集成，无需再更改任何的代码。
a) 同理2）中a)描述。
5） 易部署和升级：通过拷贝即可实现部署和升级。
a) 同理2）中a)描述。
