基于插件开发的架构设计

主要说说对基础架构调整的一些想法，很大程度是个人的一些见解，不足的地方需要大家指正，共同研讨学习。

针对目前的来讲，其实没有很好的采用3/N层架构模式开发，过多是采用业务层与数据访问层混合的形式进行开发的，并且我们目前的开发也大都是这样的，这种虽然比较快速一点，有点所见即所得的方式，但是维护起来有点不尽人意，理想中应该是纵向分层，横向分解的方式进行开发，而插件是处于横向的形式类似与AOP切面编程方式切入的。

插件的最主要的特点就是灵活，需要的时候安装，不需要的时候卸载，对基础架构的服务运行没有什么影响，这就要求插件与基础架构以及插件与插件之间的耦合性一定要松散，要想将系统做成“框架+插件”的架构形式，需要在各层上进行松耦合设计，只有松耦合的模块组件才可以做成一个插件，当然送耦合并不是没有任何关联，他们直接肯定是要进行通信的，只要不造成二者缺一不可就行了。

与其说到架构调整，不如先说一下我们的预期目标，然后在这个目标上进行调整比较好。

目标应该是以基础架构为基础，我们进行扩展比如安装我们的基本设置插件，为其他插件初始化相关信息，然后安装用户插件，为其他插件提供使用对象，然后再安装备课管理，进行备课操作使用，目前为止这些插件貌似都有依赖性，插件与插件之间进行直接通信，理想情况下应该是他们之间有一个相互约定好的插件管理层，他们之间的通信都通过调用这个插件管理层中的相关接口进行通信(个人理解)，这也是我们下一步要做的，如何让他们松耦合，这就需要我们在他们之间的通信接口上面下功夫，两者在保持接口不变的情况下，可以独立变化和发布。

                                                             

应用程序由应用程序框架、插件接口、插件和公共函数库四部分组成 。

 

　　应用程序框架负责应用程序的整体运作，它清楚程序整个流程，但并不知道每个过程具体要做什么。它在适当的时候调用一些插件，来完成真正的功能。

　　插件接口是一个协议，插件按照这个协议实现出来，就可以加入到应用程序中来。当然，对于复杂的系统，插件接口可能有多个，各自具有独立的功能。

　　插件是完成实际功能的实体，实现了要求的插件接口。尽管实现什么以及怎么实现，完全是插件自己的自由。在实际情况来，一般还是有些限制，因为插件接口本身可能就是一个限制。如，实现播放音乐功能的插件，自然不能实现成一个聊天功能的插件。

　　公共函数库是一组函数或者类，应用程序框架和插件都可以调用。应用程序框架本身是公用的，是代码复用的一种方式。但并不是所有可复用代码都可以放在框架中，特别是插件会用到的公共代码，那会造成插件对框架的依赖。把这些公共代码提取到一个独立的库中，是一种好的方法。