关于XML配置文件的想法

简介

实际的 项目开发过程中会遇到许多需要配置的场合，可以提高开发效率，增加代码的重用性，需求变更的应变能力。。。。。

 

如今我们在（两个月内）遇到的配置场景有：

接口字段的对应配置，

流程中自定义页面的控件权限配置，

自定义页面数据控件数据绑定（保存、读取）配置，

数据控件验证规则 配置，

通用查询分析报表相关功能配置。

。。。。。。。（肯定还将会遇到很多类似场合）

总结：一般于业务规则紧密相关（例如接口），需求变动平凡，重复性编码的场合一般需要配置。

 

可以看出我们在两个月内就遇到多达5 种配置场景，不采用配置方式我们将面临的是代码的难于维护，需求变更的危险性。采用配置方式，我们有专门的时间开发5 套配置界面、规则解析代码的时间么？ 没有！ 所以我们需要一套合理可行的配置解决方案。

 

主流的配置实现方式：

1．  数据库配置：

优点：以二维表的配置方式展现，DBM（数据库管理工具,此时可作为配置工具）的友好操作界面和强大的功能（支持配置数据类型化 如：int型（解决排序问题：1，10，2）），很容易定义配置结构，解析工具的强大和成熟（ADO。Net，FrameWork 1.1、2.0）。

缺点：部署不太方便移动性差，需要数据库的支持，保密性问题，配置结构过于死板。很难实现规则的整体属性配置：如：TableName

2．  XML配置：

优点：便于部署移动，修改容易（文本编译器），保密性强（必要时可以加密后存储，解密后解析），结构灵活（XML决定）。

缺点：针对每一种配置任务会有一套规则（XML格式）相对应，没有现成的规则配置工具（当规则较为复杂时难于定义格式，学习配置，准确性降低，导致配置效率的大幅度降低甚至失去快速开发的意义，例如：通用列表XML的配置），开发不同的配置工具界面（随之而来的问题：开发难度较高，开发时间的加长，专用配置工具的生存期太短（浪费，难于管理和技术进步），配置实施人员对不同工具的熟悉（浪费时间）），规则解析代码需要根据不同规则重复编写（随之而来的问题：需要测试，代码质量同开发人员相关，稳定性较差）。

 

希望可以结合以上的优点，提高配置准确性，配置结构灵活性，安全性，稳定性，容易学习使用，提高配置效率，节省开发时间，统一管理各种配置规则。

 

所以提出以下配置过程模型（方案）：

 

以往建立一套规则需要编写以上所有模块，建立5 套规则需要编写以上所有模块5次！

 

后台内核实现机制我们需要扩展性强、功能健全、稳定的解决方案，多谢Microsoft在 FrameWork 中提供的DataSet！！。它具有数据库的所有特性，有非常方便的XML转换机制，有着前所未有的强大扩展性（使得成批规则导入导出功能成为可能）。还有以微软名义保证的代码高效性、稳定性、以及每个开发人员对他的熟悉程度。。。。。

 

就用它了！！！！ 有了它图示中浅蓝色最重要的核心部分我们没有必要在浪费精力了，交给微软吧！。我们只需要作一套基于DataSet 的灵活的配置工具、以及规则读取代码。OK了！

 

按以往的开发习惯我们会为每套规则设计开发一种适合它的界面（开发工具），甚至是不去开发直接使用NoteBook 来面对XML（后来实践证明这种方法是低效的....）对于以后的配置人员来说配置工具的多样化也是非常头疼的，所以我们需要将配置界面与逻辑规则分离开来，让我们的配置工具在应用中去描述逻辑规则，以不变应万变。可能这样配置工具的开发实现会有些复杂和困难，但是幸好这个过程只有一次！！并且会在不断涌出的配置场景中不断完善、提高。还有一个很大的优点千万不要忽视-----从此配置人员可以只针对一套界面了！！

 

对于这种配置模式的扩展性和灵活性就在我思考如何写这段话的时候，一个案例使我激动不已，我甚至直道刚才才发现它的结构原来如此灵活可以描述非常复杂的配置结构。这个经典案例就是：整个工作流的配置可以用它来实现！！！

其实原理很简单：∵工作流配置在DataBase里，

而DataSet是DataBase的鲜活写照

                                   又    ∵此工具可以以配置界面方便展现DataSet

∴此工具可以展现、配置工作流的任意细节

怎样？似乎有些出乎意料，但完全又在情理之中。