【目录】-【模块化和插件化】-【概念】

　　这算是OSGi的基础和灵魂，没有他，后面将要介绍的很多功能都会黯然失色。

　　先看文档怎么说：
　　1） 物理隔离：基于UIOSP开发的模块是一个物理隔离的可单独部署的模块，每一个模块拥有独立的文件夹、类型空间、资源和类加载器。模块间互相独立、互相隔离且互不影响。
　　2） 高度可重用：模块的重用不需要再更改任何代码，只需要将模块拷贝到UIOSP指定的插件目录下，它的功能便向其它模块暴露。
　　3） 规范化：模块具有统一的标准，每一个模块的目录结构、模块配置都是统一的，开发方法也完全一致。
　　4） 快速集成：仅需要将模块都拷贝到指定的插件目录就能够实现模块功能的快速集成，无需再更改任何的代码。
　　5） 易部署和升级：通过拷贝即可实现部署和升级。

　　乍一看起来，这五个貌似是互不相干，其实他们围绕着一个最基本的最核心的点来说的，那就是“封装”，逻辑和物理兼顾的封装。

　　对于逻辑封装我们很好理解的，这是OOP干的事儿，封装变化，面向接口编程。这一点虽然是大家都常在谈的，但是要真的应用在具体业务逻辑上时，是得需要花些功夫和实践的，对于OSGi的最佳实践来说，尤其重要。
　　

　　物理封装，就是这里所说的“物理隔离”，隔离的层次级别很低，到了具体的实体文件。首先，不像是普通的.NET程序，如WinForm，默认情况下，功能程序集文件都必须是在bin目录下，和主程序一块儿，如Web，文件都是在同一个目录层次中，核心逻辑也是在这个启动路径的bin目录中，他们是紧密联系的，无法分开存放的。OSGi的目录结构是可以自定义的，你可以把程序中任意模块的路径指向到任意路径，当然这些路径都是在一个已经定义好的范围之内，在这个范围内任意位置的程序集都可以被访问的到。比如你可以把主程序放在C盘，功能模块文件放在D盘。原理上讲，就是OSGi.NET改变了.NET默认的加载顺序和机制，允许程序动态加载指定路径的程序集。

　　其次，就是物理级别的“封装变化”，对于一个程序来说，每个子功能模块，根据需求的不同，对整体而言是可变的，也是不停变化的，以前只是将逻辑封装在一个程序集里，那么是否可以将多个关联程序集再封装在一个“模块”里呢？以前是内部的封装，现在是内部和外部一起封装，更抽象的封装。逻辑封装的表现形式是一个程序集，通常就是一个具体名字的dll，这里物理的封装就是一个具体名字的文件夹，在这个文件夹里包含了他所需的多个基本的程序集。理论上说，最佳场景应该是逻辑上、物理上与其他封装好的模块之间相互独立且隔离的，这样的话，我们能很简单的从文件结构上提炼出模块之间的关系以及整个软件功能的组成，这为以后的更新、维护、部署甚至重用都带来了好处。比如一个WinForm上的封装好的数据访问模块可以直接复制到一个Web上无需改动，即可使用，这也就是所谓的“高度可重用”，“快速集成”以及“易部署和升级”，他们依赖的就是比较好的逻辑和物理封装，还有可设置的加载路径。
　　

　　再说说“规范化”，这个简单的说就是“标准的力量”，无论你如何封装，总要遵循一定的规则和指导原则，逻辑封装得尽最大可能遵守设计模式的要求，物理隔离也是同样的道理，他遵循的是OSGi.NET所设计的“自描述机制”，每个模块通过一个Manifest.xml来描述自己的诸多参数、默认设置和描述信息，例如如何启动，从哪儿启动，怎么启动，依赖关系等等，更高级的还有扩展、扩展点，服务注册等，当然还得有诸如版本，名称等基本内容。如果，两个不同的企业发布了不同的模块，但他们恰巧遵循了相同的封装原则，结果会怎样？是的，他们的模块，理论上可以被同一个用户使用在同一个程序中，这就是规范化的好处。对一个企业来说，当然大家都得遵循同一个标准，不论是应用在哪个具体的项目上，开发、迁移和重用都会很方便。
　　

　　接下来，我们具体的看一个例子，来了解一下模块化和插件化。