企业开发的很多特点，决定了其经常以数据库为中心的开发模式。不过本文要讲的是以表单为中心的开发模式，带来了不少启发。文章所述使用的是Ruby on Rails面向表单编程，不过基本理念应该是通用的。
在国内做过企业开发的人都知道，国内的企业开发往往是业务多、时间短，这是普遍现象，所以软件开发公司也都在追求快速进行企业开发的方法。很多的开发公司做企业项目的时候，都是由需求人员与客户交流，了解完需求后建立数据库表（PowerDesigner是这个领域的王者，相信很多人都用过），然后将需求文档和数据库交给开发人员（当然有的需求人员不建表，开发人员建表也常见），开发人员逐步实现需求。日后需求改变了，先修改数据库，然后修改程序上层界面。
这种开发模式以数据库为中心，上层所有开发围绕数据库进行，数据库是连接需求端与开发端的桥梁。相信国内不少公司都是采用的这种开发模式，也许正在阅读本文的读者所在公司也是吧？
当然，今天我在本文想要介绍的经验，不是以数据库为中心的开发模式，而是我认为的更高级的以表单为中心的开发模式。当然这也是我的实际工作经验。看看以下这个例子：
我们在做一个管理型项目的时候，用户给了我们上面这个Excel文件，让我们实现这个业务，这个时候需求已经很明确了，公司可以进行开发了。
假如是先前的以数据库为中心的开发模式，软件公司需求人员需要先建表，依照Excel文件，逐个添加字段。然后把Excel文件和数据库表给了开发人员，开发人员需要照着Excel文件做出软件输入界面，然后将输入域与数据库表格的字段一一对应。把上面的事情做完，就算配合娴熟的团队，至少也得一天时间了。如果这时候用户又提出，这个表单需要精确打印，随时准备盖章存档，那开发方的工作又多了很多。
以表单为中心的开发模式，不对数据库建模，而是对表单建模，采用专门的表单建模的工具，类似于Excel，将用户的Excel文件复制成模型，导出为XML格式的文件，以后这些XML文件就是我们需要维护的核心了。市场上表单建模工具有一些比较成熟的，比如用友的Cell组件，还有其他公司的报表软件。我们公司独立开发了一套工具（不对外销售），使用这套工具可以很好的进行面向表单的编程。 那么面向表单的编程如何解决上面用户提出的需求呢？
用户给我们一个Excel文件后，我们用建模工具做一个一摸一样的表单（如果工具本身支持Excel复制则更快），将表单存为XML文件后发布到程序框架中，框架程序分析XML文件后自动建表并添加字段。程序框架封装了表单的读、写、删、打印等常规操作，上层需要写代码的地方只有列表显示功能。用一个Sql语句查出需要显示的表单记录，挑出需要在列表中显示的字段即可。采用这种模式，不消20分钟，上面用户提出的需求便迎刃而解。这是最终做完后的界面之一：
除了实现上面这个界面，还可以实现更高级的功能，例如客户端验证和运算，保证某个单元格必填，或者某个单元格的值必须大于某个值，或者某几个单元格必须保证相加、乘积的关系。这些功能不必写代码了，使用表单设计器内置的功能即可。这种模式可以实现技术与业务分离。让人专注于业务，忘记技术。事实上，如果在开发项目的过程中，还在考虑用户的需求从技术上怎么实现，那无疑这个项目是很危险的。
下面是表单建模工具设计时的界面:
面向表单的编程，日后需求发生的变化，大多数集中在表单的格式及表单流程上（因为表单承载了用户的日常业务），我们只需要调整表单，重新发布就行了，不涉及到修改代码。流程改变了也是同样，修改后重新发布工作流文件即可。我想大多数软件公司做项目的时候都有自己现成的框架，事先实现诸如用户、权限这些常规的功能。基于表单的开发模式，也需要软件框架做不少事情，还需要独立的表单设计器的配合，框架上的开发量比较大。但是当框架上的积累达到很稳定、很完善的时候。拿框架来做用户的业务是很幸福的事。基于表单的开发模式+ROR的快速开发，再加上报表查询引擎和工作流引擎的支持，开发企业应用将是火箭般的速度。在那个状态做项目，将不再是跟在用户的后头听指挥，而是做的比用户说的快，能够***用户的思路，牵着用户的鼻子走，到那个时候，开发进度很好掌握，客户关系很好维护，要回项目款，自然也是不难的了。大家要更多的了解面向表单编程，可以参考用友U8和用友其他的财务软件，里面全是表格，真是彻彻底底的面向表单编程，而且用友软件其他的技术比较薄弱，界面很朴素，几乎可以说是一招走遍天下。
【编辑推荐】
