GIS应用系统中的可配置和元模型

（转载请注明出处http://xujim.github.io，谢谢）

最近研究某一开源GIS系统，感慨于可配置性，结合元模型，总结如下： 可配置的系统主要表现在如下几方面：

1. 界面可配置 表现在工具条，菜单可以根据后台配置动态修改。还包括界面布局的可配置，将界面抽象为不同的widgets，可以动态的取舍或调整。 在实现上对于布局可以采用模版的方式，工具条、菜单可配置往往基于COMMAND模式。可以通过XML或者Database描述配置方式。 实现上还是挺简单的。

2. 内容可配置（管理） 在业务逻辑固定的情况下能轻松的替换数据，更新数据内容，有CMS的特点。 另一方面，像一些googlemap等网站，使用者可以在地图上增加一些自定义的位置信息，以提供自己索引。

3. 功能可配置 和强大、灵活的权限系统结合，按照用户的角色分配不同的权限，从而提供不同的功能应用。另一方面，在成果输出功能上，如报表，统计图，还有地图。 功能可配置往往和业务挂钩，在地图输出上可配置尤其复杂，如可以设定地图背景颜色，可以修改地图布局，修改图层（个数），配置标注方式，设定图幅，比例尺，专题图渲染方式等等。

4. 扩展可配置 表现在插件式扩展上，新增功能无需修改及编译原有代码，仅仅是通过增加组件的方式达到功能扩展。由于系统可配置不用也不可能满足一切需要，所以在二次开发方式上提供开放的、多样的接口，方便后期功能上的扩充。 可扩展的机制在桌面系统中很多依赖于COM等组件技术，接口继承在其中发挥主要作用。当然结合设计模式中的COMMAND模式这种可扩展是很好实现的。 但在B/S中就比较难实现（主要在客户端），因为一个基于脚本的轻量级客户端无法依赖于组件技术。但是基于模版，结合javascript和Ajax也可实现伸缩性、扩展性良好的系统。这里的模版指协助服务器端动态生成前端脚本的模版，它使用一些标签预留好可配置的空间，然后服务器段根据请求直接对标签进行字符串替换。WebService在可扩展上也能助一臂之力。

5. 流程可配置 主要应用于工作流上，包括业务流转路由及流转条件上的控制；而且界面上可配置要求也很高。

配置信息可以保存在XML或者Database中，然后开发一个studio或者author的工具对这些配置信息进行可视化的调整配置从而达到配置系统的目的。如gcomms的Administrator或者一般webgis软件的studio或者author工具。

在B/S系统中配置信息可以是Application级的也可以是Session级的，前者所有用户都能访问到，后者当前会话用户私有。这种访问级别的控制在一些数据呈现上有特别的用处。