框架的选择逻辑请参考《开发框架的选择》。

---

       在上篇文章里提到了开发框架要满足”通过使用这个框架能够在保证质量的情况下快速的开发出产品，并且无论是产品还是框架都能够进行模块化的升级，升级完成后还不影响其他模块“的要求。除了这些开发要求外，我认为开发框架就是在制定规则，比如定制化的开发规则、数据库设计的规则、单点登录的对接规则、日志锚点添加的规则等等。业务开发人员需要在这个规则的框架内进行开发，而框架需要对规则进行解释，保证按规则开发的代码在框架范围内都能稳定、有序的运行。在制定框架的升级策略时也是要以支持这些规则为首要标准。

      在上篇文章里提到的基础功能比较好说，也很明确，满足公司未来五到十年的战略需求比较务虚。最重要的就是满足定制化的开发需求以及保证质量最下限的情况下，能最大幅度的提升开发效率这两条了。

      先看一下保证质量下限，我们能想到的方式无非以下几种。

      a：基础功能插件化将列表、数据填报、查询封装成插件，开发人员通过插件实现功能的开发，对于业务逻辑也是在通过插件提供的接口进行扩展开发。例如数据填报：点击保存时插件自动验证数据规范并收集填报的数据，收集完后通过接口将数据开发给开发人员，由开发人员对数据根据业务逻辑进行加工，加工完成后再次将数据交给插件，又插件调用数据交互模块和后台进行数据交互。

      b：代码review，安排或组织对每个业务代码进行review，通过review发现业务逻辑中的问题。

     c：测试，充分的测试，单元测试、接口测试、自测、一测、产品经理确认测试、二测、项目测试。

      这些方法中a是最好的方案，但前期需要大量的工作和设计，也需要一个两人左右的团队来维护。b方案会划分很多的精力和耐心，而且能做代码review的人一般会有更重要的工作等着他去做，这种方式只适合对于核心代码的review，另外还有一种场景是带新人的时候用。c：单元测试和接口测试可以自动化完成，其他的需要制度和专业团队的支持。

     我们选择了a作为了保证质量下限最重要的手段，插件一定程度上也能减少重复工作的开发，提升开发效率。前期只要求了两个主要插件，1、列表插件（含查询条件、分页、排序、自定义按钮、行自定义处理）功能。2、数据填报展示插件（含填报布局、字典加载、自定义选择数据、编辑、查看、默认值、自定义控件事件、数据规则验证、图片上传浏览）功能。

      对定制化的支持，差不多也是只有几种有限的待选项。

      a：大集中，将标准产品以及定制化代码放到一个代码分支下。并通过不同的配置项来实现不同的定制化需求。

      b：分支，开发完标准产品后，每个项目都在 标准产品的基础上拉一个分支，然后在标准产品的基础上修改代码实现定制化的要求。

     c：新项目+引用，新建新项目然后用过引用方式将基础版的jar包引进来，然后再通过继承重写方式实现定制化需求。

     d：基础框架+元数据，将数据库结构、页面布局、解析代码做成元数据，通过修改元数据完成定制化的要求。

     这些待选项中a理论上能满足我们的两个要求，但实际操作中代码量会越来越来大，随着人员的流动，别说对历史项目的支持了，但代码的维护就是一件很困难的事情。b方案不能满足批量升级部署的要求。

     c方案倒是可以比较好的支持两个需求，jar包的引用方式保证了标准代码不会被修改，继承重写可以通过规则进行规范。但是有两个比较棘手的问题需要解决。1、数据库扩展的需求，比如某个数据表增加了一个字段，前端可以通过修改插件配置项的方式实现，逻辑层也可以通过继承的形式实现对数据的处理，但是到了数据层如何让ORM将实体对接到新的加过字段的model是个问题。2、前端的继承问题，因为我们前端使用的插件，通过插件配置数据及扩展接口的形式 实现业务开发，问题是js不好使用引用的方式处理，还有就是JS不能继承。

     d方案可以完美的解决这个问题，就是工作量太大。

     通过对上面几种方式比对，我们最终选择了c+d的组合方案，具体设计如下。

     1、插件+元数据实现了前端的全配置化，将插件的数据项配置到数据库，并提供可视化的配置界面，这些配置项包括、对于的数据库字段、表之间的关联关系、对应的控件类型、布局位置、字典、自定义的数据接口（下拉、级联规定了数据格式）、行/列自定义处理代码、控件change方法。未来随着平台功能的升级按钮、按钮方法等都将实现元数据化。而后台则配合插件提供基础的数据增删改查标准实现，这些实现中服务层、数据层可以通过重写的方式进行自定义修改。

     2、后台使用jar包引用的方式，将标准版成打包成一个jar包，通过maven完成jar包的升级管理，在打包发布的时候也将标准版jar包和定制化jar包分开打包（类似于windows程序中exe和dll的关系），以实现标准版升级的需求。

    3、数据库的扩展采用扩展表的方式，例如某个表需要扩展字段，只需要新建一个扩展表就行了，

     另外元数据+插件+jar包的形式可以很好的支持框架的迭代升级，从数据层、服务层到前端都有自己的开发规则，开发人员需要在这些规则下开发，框架也能在这些规则下升级。另外框架也能大致实现另一个理论，框架应该要把能控制的地方控制住，需要开放的地方开放出去。

     其他的比如日志模块、服务监控模块、缓存模块都是框架内的一个功能模块，这里就不再详细介绍了