web开发平台之研究
前言
在去年我写web报表开发技术专题系列文章之时，就想写一写对web开发平台之探索。没想到一拖就是又近一年的时间过去了。前几天看到csdn首页的 如何轻松构建自己的业务应用程序 的链接，便点进去看了看，原来是电子书《创建随需应变的应用程序：Force.com 平台简介》（注册下载还可以抽奖，有兴趣可以试试，呵呵！）。花半天时间看了看，感触颇多，忍不住便写下了此文。
web开发平台之定义
从编程之初，便免不了和函数，类，抽象，接口之类的东西打交道。久而久之，自然会对此进行总结，这便是开发平台之由来。在中国的程序员之中，有很大一部分都是编一些企业信息化，政府信息化之类的程序。其特征是数据放在数据库中（如sql server库，oracle库等等），做一些增删改查之类的表单，出一些统计图表，用于对业务信息进行管理而已。随着internet的流行，自然又要求把这些都放到internet上，即web化。因为这些有一定的共性，做得多了，便会想将共性提取出来供大家共享。这便是web开发平台之初衷。
在网上，有很多差异很大的东西都称作web开发平台，为正视听，对于web开发平台，我的定义是指：
1指b/s结构的程序，即web化。
2 用于实现企业信息化，政府信息化之类的信息管理系统的开发。
3 用于快速开发对数据库进行增删改查之类的表单及统计图表
web开发平台之前身
在internet出现之前，人们就对如何实现快速开发做了很多研究。象用友金蝶都有自己的开发构件库，象SAP的ABAP开发平台等等。象SAP的ABAP开发平台太复杂，一下子很难用起来；而用友金蝶的开发平台又只能自己用，无法开放出来，即难于通用。也就是说，对于开发平台的早期研究表明：要么功能强大，使用复杂；要么难于通用。
人们还来不及对这些问题进行改进时，internet的大潮来了。这些早期的开发平台也被迫要转向web开发平台了。这些问题显然不会被internet的大潮自动冲尽。忽视早期开发平台的这些问题，没有很好地解决通用性和个性化的矛盾，正是当年ASP（应用服务提供商）失败的重要原因之一。
对于web开发平台之前身的开发平台的研究，可以积累web开发平台的经验，避免走更多的弯路。利用web的便利性，也许能独辟蹊径，一举使web开发平台实用起来。
web开发平台之乱象
下面摘录网上的一些web开发平台的介绍：
用xxx开发应用软件，会具有前所未有的高效率、高质量、高适应性。其目标是让每个应用软件开发人员成为优秀的系统分析员，而不是代码的奴隶。不用写代码便能生成各种各样的应用程序。
xxx平台是一款企业级开发工具。可以非常方便，快速，高质量的开发各种应用系统，如CRM、MIS、ERP、数据仓库、人力资源系统、资产管理系统、供应链管理系统……与传统的编码式开发不同，平台采用配置式开发。绝大部分模块均不用编写代码，只需通过平台进行参数配置即可，业务流程复杂的模块，可以采用平台自带的代码生成器方式形成基础编码，对基础编码适当优化即可完成。
Xxx平台是真正针对不断变化的需求而设计的面向构件的平台。它将构件技术、XML企业总线技术和可视化开发技术完美结合，通过图形化的构件单元作为应用系统的基本组成元素，为企业级应用系统的开发带来了卓越的价值。
Xxx平台为企业信息系统建设提供了统一的公用基础设施平台，采用“主板＋插件”的模式来构建和扩展业务系统，各类业务系统直接构架或连接到统一的协同业务平台上，并以其为基础和枢纽，将分散的企业应用管理系统整合起来，形成一个有机的、紧密联系的整体。这是一种全新的软件开发和维护模式，是以业务描述、而非代码为核心来构建信息系统。业务建模能够真正实现 “快速开发、灵活调整、业务驱动、技术无关”，充分满足“整体规划，分步实施，自我掌控，随需而变”的企业信息化长远战略规划要求。
xxx平台是依据多年开发企业管理软件的经验，推出的一款业务基础平台产品，它基于B/S架构，集OA系统、业务系统与开发平台于一体，提供了强大而灵活的定制开发功能，业务模块无限扩展，涵盖软件的需求、设计、开发、测试、实施和维护等整个生命周期，可以通过互联网随时随地访问与维护，代表了新一代管理软件体系和开发模式。
web开发平台之疑云
对于web开发平台，网上也有众多的疑惑！
行业管理软件，请把平台拿走。有什么用呀。
简单的修改，比如界面挪个位置，变个颜色。
中等的修改，做个复杂的统计报表，加个字段，改变个字段长度和类型，加个页签一个页签做录入一个页签做查询，加个浮动窗口来参照关联业务，改变业务校验规则。
复杂的修改，如当地有规定，如本企业由于历史遗留问题必须这样处理业务，你必须改变你现有的软件，不知你辛辛苦苦费了很多高深技术做出了一个家伙能做哪些？
你做平台不就是为了修改快速好节约成本而导致盈利吗？否则要平台干吗？
但是如果一个平台，只能做简单修改，也就没什么用。如果一个平台连复杂的修改也能做，我觉得它肯定复杂的像PB、DELPHI、VB、JAVA、.NET之类了，那还干脆不如用这些开发工具。这种平台食之无味，弃之可惜。只是一帮钻了一辈子技术也没有混到主管位置上的高手们的一个技术梦而已。
你以为有几个客户能定义元数据，能自己关联表做统计，能写一段SCRIPT。
还不得你们客户化中心自己做？
自己做，用自己的平台，还不如用顺手的visual studio。
你想是不是这个理？
所以别吹你们有什么ORMAPPING，OIMAPPING，实体对象，设计模式，平台。
就象咨询师一张口就是业务流程重组、组织结构、企业战略、绩效考核、团队激励
别扯淡了，有本事把程序稳定了，修改及时，支持回答疑问负责任，真心解决问题，而不是敷衍。
你们的平台如果有本事做到程序稳定，高性能，修改及时，我也服了。就怕你们都嫌这个平台连visual studio都不如。
web开发平台在软件投标过程中实现快速原型有帮助，但实际应用系统还是需要用大厂商提供的开发工具进行开发，假如一个web开发平台真那么容易实现的话，而且那么有用的话，为什么微软、IBM等公司不去做这样的工具呢？
如果你的客户端操作系统只是一种，就是WINDOWS。那么你大可不必学习新技术去开发什么WEB版本。只要软件是小模块的，有自动检测更新程序的就可以。
什么时候使用WEB?
1客户端是各种各样的操作系统
2客户不愿意客户端使用VM
3应用的界面操作要求普通，不需要调用客户端本地的硬件设备和API
但是，这种环境，对于具体的每个国内做管理软件的公司而言，这样的客户少之又少。
所以，用WEB做管理软件，没有意义。
web开发平台之深思
当我们Copy代码时，当我们一次次地重复编写类似的代码时，当我们一次次地重复编写类似的控制时，我们都会想，下次把它归一下类，省得每次改这么多地方了；等有时间了做一个工具，直接用工具配置一下就可以，不用写代码了。久而久之，开发平台就水到渠成了。从这点上看，web开发平台显然有其存在的价值，有其自然而然的需求。
收入 vs 付出
无论是什么设备机器还是别的什么东西，它到底有没有用，作用有多大？主要取决于使用它的回报与付出的比例。如付出少回报大，则其作用大。Web开发平台也是如此。如果要将web开发平台用起来需要学习或适应很多新东西，而获得的回报不大。则这样的开发平台是没有愿意用的。所以说一个有意义有作用的web开发平台显然应是需要学习的新东西要越少越好。而获得的回报（即功能的强大性）要越大越好。而这两者又是一个矛盾。向左走还是向右走？这就象哈姆雷特的“生存还是灭亡”一样，是个经典的问题。
技术平台 vs 业务平台
web开发平台是一个技术平台还是一个业务平台呢？技术平台是指由技术人员使用，业务平台是指由业务人员使用。如果web开发平台简单易用（即需要学习的新东西少），则可以是业务平台。如果web开发平台功能强大，则为技术平台。
显然，web开发平台在易用和功能强大的夹缝中，左右徘徊。寻找中间的平衡点，是每个web开发平台的设计者所必须面临的抉择。平衡点在哪里？抑或是有没有平衡点呢？还是可以跳出这个两难的魔咒呢？
web开发平台之定位
和传统开发工具(如visual studio)的关系
显而易见，web开发平台是不可能取代传统开发工具的。应是在传统的开发工具之上的封装，即是实现了一些通用性的功能，当用户需要这些通用性的功能时可以很简单的调用，遇到无法满足的功能时就要用传统开发工具来写代码来实现了。
什么人来使用web开发平台？
技术人员，业务人员（非技术人员），或是半技术人员（指懂些简单技术的人）?还是一个web开发平台的有的部分是技术人员用的，有的部分是业务人员（非技术人员）用的?
什么人来使用web开发平台这个问题看似简单，实则并不好回答，我甚至于觉得国内做所谓的开发平台的人或公司都无法回答得清这个问题，这么说，并不是指他们（指做开发平台的人或公司）没有想过这个问题，而是这个问题无法权衡清楚，常常是有时是这样认为的；有时又想法变化了。比如业务人员（非技术人员）到底能接受得了什么难度级别的东西？能接受简单的SQL？或是能接受数据库，字段，记录，主键等概念？能不能用数据库来规划设计管理自己的业务信息等等？
web开发平台之架构
一个web开发平台大体应包含如下东西：
1元数据设计
字段的信息：如中文名称，长度，数据类型，输入方式等等；表信息：表间关系，主键，外键，中文名称等等。
一个单据，常分为主从两部分。每部分的字段中文名要录入进去，以为了界面设计。有些字段的录入是参照字典的，哪些字段参照哪些字段，也做个关联，这就是最简单实用的元数据设计。
2单据设计
界面运行期动态拖拉的控件多的是，增加单据头，还是细目，有了元数据就好办多了
单据上的控件不外乎日期、文本、数字、字典参照、CHECK、GRID，
BUTTON、PAGECONTROL、TREE等等，这样，就解决了客户要界面变，录入的字段要增加减少，验证要改变的要求，控件的颜色、长度、约束条件、是否必填、中文名、跳转顺序，你可以存在表里面，也可以保存在表单文件中。
3单据保存
这个单据对的什么主从表，有字典对照就可以了
主从表的提交和单表的提交，都很简单，这很通用。
这样录入就完成了。但是，我们这里还缺三块的描述，一个是录入和浏览细目的GRID，一个是字典参照控件，一个是通用字典录入。
4录入和浏览细目的GRID、字典参照控件、通用字典录入
对于字典参照控件，肯定就是一个模糊检索EDIT和一个检索出来的结果显示的GRID。
对于录入细目和浏览用的GRID，需要过滤、定位、列的排列先后顺序，哪些列可视。这种功能，在单据录入的GRID中一样通用。
有时候录入的时候发现字典条目没有，就需要增加。这里就用到通用字典录入。
当然，你可以为每一个字典录入做一个模块。这样：在录入单据时也可以用，单独调用也可以专门录入字典。
每个字典录入界面，在表中记录好对应哪个字典表。这样，在程序的任何地方，你都可以调用起这个窗口
输入界面做完了，字典维护也完了，就剩下查询和报表了
5数据查询与报表
查询条件千变万化，但都在单据的可选字段之中。本质上就是用单据表中的某个列进行查询过滤，结果输出到GRID中。报表其实和查询一样，只不过查询是输出为GRID。但是报表又分为普通二维表、交叉表、图表、套打表、固定行列表、多源、关联分片、不规则分组、自由格间运算。
报表的查询条件设计和查询一样的原理。报表的设计需要单独的设计工具。要在主程序中打印预览报表，也要能调出查询条件，能将报表结果导出为Excel pdf 等文件。
6工作流，集成工作流引擎，能够对业务流程进行灵活的定义。业务流程定义的结果以元数据的方式保存在数据库中，运行时由工作流引擎根据元数据的描述驱动，业务单据都可以通过工作流进行驱动，从而实现业务流和数据流的统一。
7基座
输入输出都有了，就应该有个基座把这些功能都装进去，而且要根据每个人的登陆权限动态装入，基座的作用就是验证用户登录是否正确，从服务器上取回用户的配置信息，根据权限分配，建立用户功能菜单，点击菜单的时候就装入模块。
8组织结构设计、权限分配
组织结构设计：需要有集团-公司-部门-人这样的维护界面。人又归类为一些角色。角色包含角色特有的功能。这样你在分配权限的时候，就非常容易先给一个人分配一个角色，这样标准功能就都有了，如果这个人还有特殊性，就个别再增删功能。角色也有高低，这样在使用同一个模块是，如查询我手下所有人的工作单。我是小组长，我就只能看我这个小组的人的工作单，我是科长，我就能看所有小组长，包括各组下的普通员工的工作单。
而权限，这在架构上很有要求。权限分配分为三类：
业务功能权限分配，要能分配到这个模块的每个按钮功能及子功能，大多数普通的管理软件，只能到模块。一个模块，不同的人使用应该有不同的权限。有人就能看，有人就能删除，有人就能修改，有人就能增加。而且更特殊的是，科长能录入负值，其他人不能录入负值。这些很细的功能权限都要分配到。字典权限的分配。有人就能看，有人就能删除，有人就能修改，有人就能增加。报表权限。有的人能看这张，有的人能看那张。更深入的是：有的人能打印这张，能导出这样。有的人不能导出数据。
管理，管理，就是定规则，然后执行。所以权限是定规则过程，执行就是日常使用了。
9还有一些公共业务函数和使用公共数据库连接池，就放在公共模块中，让普通业务程序员调用。做OpenApi，开放的web服务，供外部实现mash-up（一个网站或应用程序，将来自多个随需应变平台的工具组合起来创建新功能）。
10还有一些外围的功能，如软件加密，导入用户以前的数据，安装数据库而不是恢复备份，标示这个软件是什么版本打了什么补丁，这样在追查错误时比较容易判定是什么版本。
还有一些，就是登陆日志记录，软件操作错误就把错误记录下来，把界面屏幕抓下来。
当然，如单据审批工作流，单据回溯追单一查到底关联查询，如短信的结合，如单据确认消息发送，这些都是外围的一部份，但却是很重要很实用的功能。
web开发平台之实战
如何开始着手实现web开发平台，一般是从常用控件的开发时起，比如开发：tab页控件，dropdownlist下拉列表控件，表格grid控件等等。等控件做得差不多了，就需要一个可视化的设计界面来用于布局这些控件了。这样做下去了，便成了我做的eform自定义表单工具了。
自定义表单工具用于完成表单界面的设计，布局。对数据库中的数据实现增加，修改，删除，查询。它可以在投入使用的同时进行开发，开发和使用即在一个平台上却又互不影响；这一特征使得软件可以更快的提供给客户使用，从而更好的适应客户需求变更；同时为软件维护和变更带来革命，作为维护人员你再也不需要客户、公司来回的跑啦，现场就修改吧。它最大的特点是表单修改后无需编译就可运行，表单设计器也是web页实现的，无需下载插件，可视化设计，控件丰富，包含：button,label,textbox,combobox,listbox,radio,checkbox,textarea,div,超级链接,页签,dataset,img,shape,checkboxlist,radiolist,dbimg,upload,table,grid,dropdownlist,spin,tree等等。详见：http://www.fcsoft.com.cn/eForm.htm
除了表单设计器之外，还有一个非常通用的就是报表工具。对于报表工具我是用e表来实现的，e表分e表 for .NET版和e表 for Java版，分别用c#语言和JAVA语言实现。用e表来实现复杂的统计报表。它采用类Excel报表设计器，通过多源、分片、不规则分组、双向扩展来轻松拖拽做复杂格式的报表，做报表从此不再需要编写复杂的SQL语句和做大量的前期数据准备了，不仅不需要编程而且大大降低了报表后期的维护量，将制作报表的效率提高了一个数量级，彻底地解决了困扰中国报表领域十多年的难题。详见：http://www.fcsoft.com.cn/webreport.htm
除这两个之外，还有象工作流等等暂时我是没有时间和精力去研究了。
web开发平台之顿悟
它山之石，可以攻玉。还是来看看salesforce的web开发平台吧！在《创建随需应变的应用程序：Force.com 平台简介》中主要说明了web开发平台实现一个招聘程序的过程。
定位给业务人员使用的。对技术要求较低。不过，我想在其内部一定有一层清晰的开发平台。也就是说，其实质是用两层平台来分别应对简单易用和功能强大性。这两层平台之间又是相互联系的，即面向业务人员用的这层平台很可能是由背后的平台生成简化而来的。如下图所示的两层平台，分别应对简单易用和功能强大性。
由此可见，先有一个功能强大的开发平台，由它来应对复杂的功能。然后由此生成简化一个面向业务人员使用的平台。由这两层平台同时提供给用户使用。同时使用在一个应用中。业务人员用简单易用的平台来完成一些基本的功能，技术人员用底层的平台来完成复杂多变的特性。再辅于开放的api，web服务供外部集成。这似乎是一种圆满的web开发平台解决方案也未可知。
Web开发平台一旦用起来了，可以很大的提高团队开发的效率。等大家实现了，你会发现，你给了程序员业务描述说明，里面包含要写的表和界面和功能操作说明，给了他数据库结构说明，数据库设计员写好SP和VIEW，普通程序员很快就能做出一个功能和改变一个功能。如果再加上这个普通程序员写的代码风格统一规范，小函数封装，界面和功能分离，即使没有什么OO和UML，这个产品仍然容易定制和修改。作为一个技术架构师，就是提供工具和公共功能，并且联合数据库设计师或自己合并担当数据库设计， 使软件就高性能、稳定、安全、可裁减修改。一个软件的终极目标不就是这些吗？如果这些都实现了，普通程序员的地位又是怎样呢？项目经理负责进度和业务描述和质量、架构师负责上述架构、普通开发人员和测试人员保证产品出来、售前售后培训人员调研客户需求培训人员、普通实施技术人员和普通支持人员做好支持。一个梦之队就产生了。中国的软件公司大部分都是50人以下，UML、OO、模式、软件工程，都是不现实的。从目前来看，不乏项目经理，也不乏架构师，因为一个开发团队，只需要一个项目经理和一个架构师。而目前中国软件业特别需要普通程序员。但是很低的工资很少可做的工作，对于本科毕业的大学生来说，这简直就是浪费人才。但是，没办法。就像传统行业，现在特别缺技术工人，农民工太低，城市下岗人太老，本科生不愿意下车间，但是没有人愿意上职高和中专。这就是现状，你不接受也得接受。你接受不接受？我们唯一能做的就是利用现有的资源，把事情做到最好。中国人的奇迹一般都是这么创造的。
web开发平台之明天
毫无疑问，在不久的将来，web开发平台将依然在迷雾中前行。依然会有一批批执着的程序员抱着各种各样的美好梦想投身进来。几十年了，人月神话依然是一个神话。或许，这也象是永动机一样是个无解之题。或许，这只是看上去很美而已，永远无法落地成为真实。或许，它挑战了人类的极限，引来了上帝的笑话。
在社会分工越来越细的今天，想让业务人员来搭建自己的信息系统，这个方向本身就值得怀疑。当然，在中国，怀着各种各样目的，编造不可能实现的慌言，来蒙骗不懂得技术的人，这似乎成了一种主流。从早期的ERP到当今如火如荼SOA。使得用户不得不察亮双眼，来寻找自己的真正需要。
只要能真正提高编程工作的效率，就会受到用户的青睐，就会有持久的生命力和存在的价值。
