有兴趣这可以留mail:我将演示的avi发送。
15m.
大家说得平台,使用过,感觉还不错.可以说是真正的面向对象吧.有兴趣的可以看一下www.remedy.com。
你们这些平台我都看了一下，首要前提必须是多层结构，表现层和、业务逻辑层和持久化层能完全独立分开，目前能够做到这点的技术基本有两种：EJB或Spring/Hibernate。
为了不让外行人被迷乱眼睛，可以直接地说：你们的业务构建平台产品如果不采取这些技术，就不是真正多层结构，就无法做到真正松耦合，还是以前C/S传统系统的老问题：可维护性差；拓展性差等。
如果有人不明白为什么分层才能达到松耦合，那么建议读一下面向对象和设计模式等基础设计概念。
我想emaker能达到你的需求，
http://www.interinfo.com.cn/download/emaker3.exe
产品介绍
一 Emaker3产品主要适合的行业
Emaker3是一个基于B/S架构的企业应用系统开发平台，是一个完全支持构建式开发的开发工具，适合任何行业的基于B/S系统的自主开发，主要包括政府机关电子政务，电子行业，纺织行业，银行证券业，学校校务等行业的应用系统。更适合软件公司的项目开发或者在Emaker3之上开发自己的产品，例如：人力资源管理系统，进销存管理系统等。所以说 Emaker3无论对企事业单位还是软件公司都是一个很好的工具平台。
二 Emaker3的功能说明
Emaker3包括了开发过程中需要的所有开发工具所具备的功能。包括： J-Form ( 企业窗体开发工具 ) 、 J-Flow( 窗体流程设定工具 ) 、 J-EIS( 决策图形产生器 ) 、J-Documents( 系统文档管理器 ) ，权限控制中心等工具。
开发人员只需要在服务器上安装Emaker，就可以在客户端投入个人或者团队的开发，可以方便完成项目管理和版本控制。Emaker捆绑了自己开发的服务器引擎JavaComposer，同样也可以发布到其他Web服务器（Tomcat）和应用服务器(BEA Weblogic ,IBM WebSphere ,JBoss)之上，方便对多种数据库的连接设定，支持工作流图形化设定，以及PDA无线签核，支持多国语言自动转化，报表打印，数据方便导入导出，系统文档的自动生成。客户端默认是APPLET程序，同时也可以以网页方式呈现，Emaker的表单页面可以导成JSP，可以方便整合其他应用系统。
三 Emaker3的技术特点
Emaker3是一套真正意义上的支持构件式开发平台,底层遵循MVC的开发模式，所有功能都是组件化的操作，开发人员只需要通过拖拉点选就可以完成应用系统的开发，节省了70%代码，开发人员只需要掌握具体业务的需求，不需要编写代码的经验。开发人员不需要在客户端安装任何开发工具，在Emaker3平台上就可以实现需求分析―>详细设计―>表单设计设计―>联调测试 ―>上线实施―>投入使用，整个软件开发过程。
Emaker3不但极大地提高了开发效率，降低了对开发人员的技术要求，节约了人力成本，而且开发完成的系统方便修改，维护，升级。
四 Emaker3开发语言和开发环境
Emaker3是采用纯JAVA语言开发，JDK1.2,JDK1.3,JDK1.4 ,1.5都使用过，之外没有使用任何开源的代码。
Emaker3可以安装在任何操作系统之上（Windows,Linux,Unix,Soloaris等），我们目前提供的版本有windows安装版和Linux安装版，用户最好使用JDK1.2以上版本。
五 Emaker3对数据库的支持
Emaker3只需要简单设定就可以通过JDBC或者ODBC连接到各种数据库，其中包括关系型数据库和非关系型数据库，Emaker3已经包括了这些数据库不同版本的JDBC驱动程序，主要有：Oracle，MS SQL Server,My SQL,Informix,Sybase,DB2,AS400,Access等等。
其实“解耦”两个字真不是说说那么简单，这条路是漫长探索之路，绝不是就是那两下子，现在各种工具的出现以及应用系统水平高低衡量只有一个标准：解耦。构件的基础就是解耦。
AOP是解耦的最新设计思想，但是远还没有达到解耦的终极目标，Spring将J2EE的各个部件都可以拆开和组装了，但是又造成了业务构件和某方面Aspect构件耦合在一起，所以，一个好的源框架必须还是必须从业务视角着手，OsWorkFlow这样的工作流组件虽然实现可配置流程，但是它一个流程涉及到界面流程和业务流程，他们又不能很好地解决这两种解耦。
Jdon框架目前在探索将业务构件和Aspect构件彻底分开，吸取工作流组件中可自定义配置流程的特点，提供Aspect方面的自定义，这样，流程也可以成为一个Aspect定于，这是Jdon Framework 1.2版本的设计概想。
要做一个快速构件平台很简单，但是做成一个能分能合的软件就不容易，现在很多软件工具在这两个方面都不能顾及，其征途路漫漫长远。所谓“分”就是解耦，所谓“合”就是快速开发。
构件平台到底应该走什么样的路。
构件平身的清晰定义是怎么样。
我还没想明白，可否有高人指点一二
普元eos我摸过一段时间，总的来说能够做到这个程度已经很不错，但我觉得在eos系统中构件的概念依然比较模糊，并未清晰的给人展现出一种独立性，构件接口也不够清晰。
并且eos里面使用的技术仍是重量级容器技术，是否是构件平台的发展方向?
业务构件平台不能只考虑快速，灵活性质量必须兼顾：
业务平台作为一个软件，首先我们必须搞清楚软件的最大目标或者说重要方向是什么，不能因为快速而丧失软件的本质，追求松耦合是软件的最重要目标，那么是否和快速性构成矛盾呢，在下面帖子有继续的讨论：
认可你的说法，普元在eos上投入了很多很多，能有今天也不容易；但给我感觉他们缺少足够水平的构架师；另外刘亚东最初购买的那个团队的整体水平好像不够高；瞎猜猜；
eos的构建速度不是很认同，另外复杂度有些高；
做业务构件平台四年多，深刻体会到方向的重要性，作为前沿的东西可能有千百条路可以走，也许只有一条是正确的，谁找到了？
编程开发被大量摒弃是必然，不过要以非编程方式解决千变万化的复杂业务应用要花好多脑筋，重要的是如何决定构件的粒度；
最近公司刚刚完成一个银行的项目，15个模块，基于平台开发，没有编写一行java代码，总体让人满意，客户也很满意；
重新回到这个问题，很高兴能够看到这么多的同仁能够关注这样的问题
我现在的思路是：
1、基于一个成熟且可扩展的内核，如开发工具使用eclipse，程序框架使用sstruts＋pring＋hibernate等等
2、在此基础上结合自己的业务需求，进行功能扩展，包括开发工具中的业务系统、模块的建模，运行时的服务，以及管理控制台
最近看过一些IBM和MS，以及其他厂家做的类似东西，确实没有一个真正意义上的解决办法，实用＋灵活＋高可靠性，呵呵，我比较理想主意，但是实际又相差甚远，继续寻找出路中...
做的如何了？
做得到.
我认为banq根本就没理解什么叫业务构建平台。你说的解耦、多层是框架的特性，跟业务构建平台有什么关系？我所理解的“平台”应该是一个针对某特定框架，某特定领域的代码自动化生成工具；或者说是基于某个框架、某个领域的二次开发平台。
我们也在做类似的东东，虽然还远不及上面诸位仁兄做的那么深入，不过也达到了简化开发提交效率的最大目标。
上面各位很高兴能有关于这方面的讨论，zjsun
这位兄弟，提出了很多想法和我这里团队开发的平台十分相像，我们的平台名称就叫快速开发平台(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。我很希望有更多的朋友加入讨论。