讨论：想做一个快速业务构件平台不是那么简单，谈谈你的看法

很长时间后，我们通过积累总结出用户其实想要的一个平台：

对开发和维护人员：
 无须掌握各种复杂的编程语言并了解具体技术的实现，就可以构建出满足用户需求的应用
 能够支持快速原型开发，支持在和最终用户交互过程中快速完成开发，并能够进行快速调整以适应用户需求变更
 能够支持团队协作开发，开发的资源可以共享
 需要支持自定义构件扩展，用于完成对一些共性功能的集中开发和持续复用
 在应用遇到问题时，可以方便的进行跟踪和调试
对系统管理人员：
 系统可以比较容易的进行部署
 支持应用热部署,在不影响其他应用正常运行的情况完成新应用部署或已有应用更新
 系统能够确保稳定，保持高的可靠性和安全性，
 对正在运行的应用能够方便地进行管理和监控
对最终用户：
 速度快，进入一个应用的时间能够在3s以内
 操作简单，最好能够在一个界面中完成相关操作，并且能够减少用户误操作的机会
 界面美观、友好
对管理层：
 能够统一校内应用的开发和维护模式，保持应用的整体性，降低总体拥有成本
 能够降低因技术升级(包括服务器、操作系统、数据库系统)导致应用系统重新开发的风险，并能够获得技术升级所带来的好处
 要求系统能够尽量遵循标准规范，便于应用集成的实现

如果有一个平台能够满足上述的各条件，应该可以说相当完美，我们经过长时间的研发，想努力实现上述目标，但是到目前为止还是相差甚远：想要使用简单（包括简单开发），平台不能做的过于复杂；想要系统扩展性好，需要复杂的层次但不能使使用者感到难用；想要保持高性能，就......

今天我把它摆在大家面前，也让大家一起来共同讨论这个“千古难题”，即用户所要的不仅仅是“所见即所得”，最好是“所想即所得”。

如果要做这样的一个平台，建议使用什么架构？

没有人参与这样的讨论么?

这个好像就是目前J2EE试图达到的目标。

我对软件技术复杂与简单的辩证概念是：能够放得出去；也能收得回来。
我认为目前J2EE已经能够做到非常细化复杂能够让用户按照自己的意愿介入一个系统的任何层次和单元，而且它们之间是几乎独立解藕的；虽然如此复杂，但期望使用时又能够快速自如，如同一个整体使用，这属于收得回来，这就必须辅助一定的框架，目前以MDA为方向的框架系统正在向这个方向努力，JdonFramework也是希望能够达到快速开发的一种尝试。

感谢banq能够关注我的话题！

基于MDA思想，我们通过将近2年的时间研发了一套“业务构建平台”，大概包括建模工具（数据建模、应用建模、权限建模、流程建模、报表建模等）、运行支撑环境（基于J2EE）两大部分，通过几个点的实施下来，发现还是远远不能满足要求（针对我上面提到的用户要求）

MDA的实现，我个人认为目前有两种方式：
1）编译型：通过模型来生成代码，通过编译打包发布之后以二进制的形式运行
2）解释型：通过运行时支撑平台（即通常所称的是“引擎”）来解释模型执行

两者除了实现上的差异，还有如下几点关注：
1）实现上的难易程度
2）最终的性能
3）稳定和可靠性
...

考虑到种种因素，我们的平台当初选择了解释型的实现方式，目前面临如下问题：
1）性能问题（用户最关心的）
2）可扩展性和灵活性（由于当初的设计没有考虑的太多，导致今天想加一些功能都是伤筋动骨的）

以上两点是目前最头疼的，其实我上面提到的用户需求当中，当前的版本还有很多问题没有解决

最近比较多的时间都在取舍之间，犹豫不决，郁闷之极，在jdon上将我的想法提出来，不知各位有没有好的解决办法？

MDA当然是编译型比较好，关键是你的构建平台要符合多层结构，处处体现可扩展性、可重用性、松耦合。

如果你的MDA做到realmethods的那样http://realmethods.com/
就应该解决你问题了

很高兴能看到ZJSUN在这里把问题提出来，以前作为这个平台开发者中的一员有很多不得不说……可又无从说起

平台的目标是好的，但是与MDA还有很大的差距……规范话和标准化就做的很不好

希望平台的开发组的成员能多开括一点视野，http://realmethods.com/就很不错，提出来给GUO看看，希望不要再闭门造车了

>平台的目标是好的，但是与MDA还有很大的差距……规范话和标准化就做的很不好

哈哈，原来你们都是在一起共事的，现在关键是如何实现，规范化、标准化还是只是空洞的要求，参与设计人员必须牢固掌握分层、解耦、封装等设计概念，同时对新的好的设计理念也要非常熟悉，采取国际流行的设计概念可起到事半功倍的效果，例如：AOP/Ioc、 JMI、XMI、MetaModel等等，这些标准和事实经验都要遵循，给自己的产品加入新的血液。

这是J2EE业界目前共同追求的目标，关键看谁先做出来，做得成熟和有可预见性、灵活性。

Jdon框架也是一只缓慢向这个方向爬行的蜗牛，原始目标是我自己使用顺手就可以，也在寻求更多有设计理念、有时间的道友一起加入啊。

好久没来这里了，最近一直在解决平台的性能问题。

今天上来居然看到你chimae了，有什么好想法和大家共享一下啊？

banq，尽管我的时间有限（水平也很有限），但我还是想加入，与各位多多交流，不知我该如何做？

请问哪里有已经做好的"行业应用框架"模板?我们下载来修改一下就可以运行?
请问哪里有"应用框架"的设计方法和思想?

我来简单介绍一下我们的平台（我们称他为“业务构建平台”）：
简单的说是一个快速开发平台，开发过程（平台提供的工具）：
1、数据建模：数据库实体表、视图、关系等的建立
2、应用建模：通过上面定义的数据模型，自动生成应用JSP页面，提供数据的增、删、改、查、校验、动态感应提示等功能，并提供一系列二次开发接口：数据展现处理、数据操作处理、数据保存处理等。对于查询，对所有生成的JSP页面已经集成了通用接口，只需要向这个JSP提交（submit）相应的参数即可。
3、权限建模：定义who（角色）对resource（数据）能够进行哪些操作（action）。目前只实现了数据权限的控制（包括数据的查看、修改、新增、删除的控制），以后需要扩展到上层次的权限控制，如：功能操作、模块页面级的控制

当然，我们还在业务构建平台上基础上还有一套工作流平台，用来解决业务协作问题，还有报表数据分析平台（目前与业务构建平台关系不大，由于历史遗留原因）

平台越做越大，代码越来越乱，经历了“几代人”，我是唯一支撑到现在的成员，曾经想重整现有代码，迫于用户以及项目实施的压力，一直没有敢开刀，功能还不是很完善，新的需求又开始堆积，真不知该如何是好？

>对于查询，对所有生成的JSP页面已经集成了通用接口，只需要向这个JSP提交（submit）相应的参数即可。

包括切换同一实体对象不同的维护模式、过滤条件、排序、分页调整、自定义列显示等

业务构件平台……
国内一些电信软件开发商使用了一个号称银弹的面向构件的开发平台，叫做EOS。这个东东设计了一个基于J2EE的框架，把常用的操作封装成一个个的构件，并同时有相应的IDE支持。系统在运行时通过XML的配置定义数据结构和业务流程，调用其写好的构件，输出XML数据流，并通过tag展现到web层。实际工作中这个东西确实有方便的地方，加速了系统的开发过程。不过最大的问题来了，有了这个东西之后，所有的系统分析和设计就跟OO无关了，所有工作只要围绕数据库实体模型来就OK了，调用个数据库操作的构件（比如执行sql的构件，写好sql语句），输出结果……用的过程感到很失落……
没有了OO，实际应用过程中自然有好多的问题，构件复用粒度太大，造成灵活性很低，而实际开发速度好像也快不了多少。这个号称银弹的东西自然被骂了好多，但是它确实能满足我们的需求，似乎也能满足楼主说的那些需求。
这里我就不明白了，对于这么一个构件平台，是不是应该加上一条需求：为了加快开发人员上手，加快开发速度，构建平台应该是面向数据库操作的，而不是面向对象的？

凌科软件的elinkBSP就是你说的这样的平台，只要设计人员能想到的就能迅速的实现。www.elingke.com 上有详细介绍

奉劝你们，不要做这个层面上的事情。找个现成的，得到验证的框架，或者去找普元公司。或者去找IBM公司，依托那些个大公司的技术。不就是花点钱吗?!把自己的精力集中到业务和服务上来。