通用页面框架CmPage(二)：业务模块的基本思路

首先，考虑一下典型的信息管理系统，不管是C/S还是B/S，每个业务模块都长得差不多，只是数据和业务逻辑变化了，基本操作方式也雷同，其次，我们看B-JUI这个典型的后台管理UI框架，单页应用，通过ajax进行HTML片段的刷新，各种页面控件的封装，一些ajax交互逻辑的封装，尤其有了DataGrid(类似于JqGrid的表格控件)，看起来我们只要按他的规则填充业务数据就行了，嗯，差不多，但实际的业务场景要复杂的多，前端和后端的逻辑会增加到五花八门、眼花缭乱，因此，我考虑把逻辑变化的部分还是放到后端实现，形成HTML片段后输出到UI框架中，这样可以充分利用一些我们熟知的设计模式来实现模块逻辑的迭代和扩展。

随着ES6的发布，JavaScript语法层面已经接近主流语言了，可以实现企业级的应用，当然，最主要地还是找到了一些比较好的开源框架，把他们结合起来，从操作逻辑、界面展示、数据处理等方面进一步提炼业务模块间的共性，形成开发框架，具体项目的业务模块可以从相应的公共类继承，增减特殊的业务逻辑和界面处理，当然，也可以绕过框架对某个业务模块做定制开发。

页面处理部分的文件结构如图：

model中page.js是基类，其他需要界面处理的类继承page，扩展相应的方法以处理不同的界面类型，具体的业务模块则可以选择性地继承他们。框架提供统一的URL入口，通过传入业务模块名称(modulename)，取得事先配置好的列表、编辑、查询、按钮等参数，调用相应的业务处理类进行解析、组合成HTML片段输出到前端。

page.js对模块界面的各个部分进行了拆分处理，分别组装，具体业务模块继承公共类后可以重写或者增加方法来实现具体的业务逻辑，框架也提供了很多增加逻辑的入口方法。

CmPage是个面向程序员的开发框架，傻瓜化、无代码化地设计业务模块并不是我们的目标，采用NodeJS也是基于这个思想，我希望自己编程的时候应该尽量灵活而高效，但业务逻辑的实现细节也要尽在掌握，好比无论何时何地，我们在代码中看到一个变量，虽然它是动态类型的，但我们确实知道它是在哪里声明的、也清楚里面保存的数据类型和实际业务含义。

本框架是基于原C#框架的思想用NodeJS重新实现的，并作了很多改良，也体会了用动态语言开发方式的不同之处，总体还是优大于劣的，值得转过来。