这位兄弟，提出了很多想法和我这里团队开发的平台十分相像，我们的平台名称就叫快速开发平台(Rapid Application Builder)我觉得要做一个十分庞大的快速构件平台，从目前国内来看可能性不是很大，如果将开发人员全部套死在平台框架中，我想很多程序员都会觉得不是很舒服。在这里我想提提我作为RAB平台作者的一些想法，如果提的有什么不对，恕小弟水平有限。
我们的快速开发理念其实就是节约开发过程中的成本，诚然我的目标也是在快速开发的同时保留足够的开放性和扩展性。所以整体架构还是基于J2EE的分布式架构。当然快速开发是我们的根本目的，所以框架所提供的功能就是降低开发的工作量。我在设计之初就认为表现层GUI的工作量是整个开发过程中，反复最厉害，工作量最大的地方。所以我们的平台更加专注于解决表现层问题。而传统的B/S结构已经很难适应快速开发的需求，无论实在开发的效率还是用户操作的友好性稳定性。所以我们采用Swing外加Java Web Start作为表现层。
我们有长期从事Swing开发的经验，对Swing的底层技术十分了解，所以我们首先开发了一套Swing组件，我认为纯Java的组件有良好的封装性和扩展性，所以我们设计之初就通过接口的定义，使组件有良好的扩展性，可以完全兼容SWT组件。Web Start也提供了我们和B/S架构一样的自动安装和更新的功能。而且Swing在使用下来性能方面远远剩余B/S架构，稳定性远远高出了AJAX。
我认为让程序员所见即所得远远不够，让用户所见即所得才能解决根本问题，所以我做了一套GUI设计器，和大多数产品公司的GUI设计器不同，我的设计器完全是和最终的运行环境完全结合，非但可以通过GUI设计器创建一个GUI，就算最终用户使用时也可以进行随心所与的调整。此外我们设计了组件库机制，通过工具为数据库每一个需要展现的字段分配一个UI组件，包括这个字段需要展现时的掩码，长度，大小写，格式，国际化资源键等等，这样在UI设计时，可以直接从组件库中选择要展现的字段，拖入界面中即可，同时我们的MVC是一种动态的MVC，Model的字段以及其层次的关系完全由页面驱动，即用户需要看到什么数据字段，那Model中就有什么字段，绑定当然也是完全自动的。与Web的MVC相比，我们更加注重多层次的数据绑定，我们将业务之间的复杂关系尽量都在页面中实现，当然这个还是靠我们强大的数据表格组件支持。表现层最终的存储形式我们也zjsun一样采用的是解释机制，用xml来表明具体的使用控件，控件的属性位置。此外我们还对Model做了镜像，也就是再作修改操作时，保存修改前的数据，提交UI数据时，只提交修改后的数据，这样大大减小了数据传输量。
我们还做了一个页面Lazy Loading的机制，就是当有传统的Tab页存在时，第一次装载，只会实例化用户所见的组件，而看不见的组件只有等到点上的时候才能实例化，这样我们就算再复杂的UI，装载速度也非常快，加上我们采用SAX解析UI的xml，我们打开一个非常复杂的UI一般最多只要3s不到，Lazy Loading对于开发人员来说也是完全透明的，这是因为我们的组件对于开发人员来说完全接口化，开发人员不用关心具体的组件实例对象，所以我们实现了一套Fake组件，其只是实现组件接口，在UI解析时，如果需要Lazy Loading的组件，他只会实例化Fake组件，而Fake组件不需要利用图形资源所以的开销十分的小，可以忽略不计，而除了图形资源外，Fake组件包含了全部组件功能，包括enable,visiable，位置设定，还有数据绑定的特性，所以开发人员如果需要对Lazy Loading组件进行操作时不用关心其是否时Lazy组件一样可以操作，而当Lazy组件需要真正实例化时，我们会将其对应的Fake组件数据传递给真正的实例组件。
在服务器端，我们用的是传统的Stateless Bean作为Facade组件，我们的快速开发理念就是后端提供一个通用的CRUD组件，根据前台的Model来驱动对数据库进行CRUD操作。我们完全拆散了ORM的概念，将其分为OM和RM，在做CUD操作时，我们会按照Model的关系层次，按照最简单的主从关系进行单表的OM操作。在查询操作时，我们会利用RM的关系按照主从关系进行SQL的自动拼接。这样就完成了GUI的数据完全自动的Persistence。ORM的拆分，也是的我们的Persistence技术又很强的扩展性，因为对于Persistence来说我们最后都是对单表进行操作，基本不会用到级连功能，所以我们完全可以抽象出对于单表的CRUD接口，然后通过不同实现的适配器加其操作，比如Hibernate,JDO等等。其性能进过我们长期测试不存在任何问题。当然通用的CRUD对于处理复杂的业务逻辑来说远远不够，我们利用AOP的思想对于通用CRUD组件进行了拦截操作，也就是在其CRUD操作的之前或者之后，进行增强，或者直接拦截操作。这样对于大多数情况下的业务处理，既可以利用CRUD组件提供的大部分功能，也可以对其某些特定逻辑增强。由于利用Facade模式，我们前后台逻辑的调用有可能没有足够的OO化，所以我们采用了和RMI一样的原理，利用Groovy实现了Stub，利用和Spring的BeanFactory一样的设计方式――面向业务接口的调用，当需要调用后台逻辑，我们会用Groovy生成一个Stub代理前台的调用通过Facade委派给后台特定的逻辑组件返回结果，这些对于调用者来说完全透明，对于复杂的逻辑抽象的更好的话，可以完全做到前后台逻辑无关。
当然除了上面这些技术核心之外，我们还有完善的基于角色的Privilege Infrastructure, Menu Setup，Module Setup等等一些外围的基础设施。还有基于Groovy的业务规则引擎，基于企业内部组织结构客户化设定(UI的xml文件，或者业务规则)。我们还有动态的报表引擎（JasperReport，可以让用户在运行时修改报表的布局，字体，甚至文字（国外这种是绝对不允许的，国内我们几个客户强烈要求这个功能，因为可以做假账），修改完之后也可以保存修改后的布局，我们还整合了IReport和我们报表数据源框架（也是基于XML的数据源定义框架）使用户可以在运行时直接通过IReport和提供的数据源通过拖拽的方式创建一张新报表。
可以看出我们的平台和业务数据源结合十分紧密，无论是UI，还是Persistence,还是报表，这其实就是我们核心思想的体现，我认为快速平台真正需要实现就是需要有强大的GUI和完整的数据源的支持。在这基础上实现诸如工作流，规则引擎等等一系列的子系统拿就不是什么难事。而在这些基础架构上实现的项目，甚至产品也会有很强的生命力。
如果有朋友对我们的平台有兴趣，或者希望交流一些技术，可以直接联系我，我的msn是xiefeng2002@hotmail.com。我很希望有更多的朋友加入讨论。