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

概述 很长时间后，我们通过积累总结出用户其实想要的一个平台： 对开发和维护人员：  无须掌握各种复杂的编程语言并了解具体技术的实现，就可以构建出满足用户需求的应用  能够支持快速原型开发，支持在和最终用户交互过程中快速完成开发，并能够进行快速调整以适应用户需求变更  能够支持团队协作开发，开发的资源可以共享  需要支持自定义构件扩展，用于完成对一些共性功能的集中开发和持续复用  在应用遇到问

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

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

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

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

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

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

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

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

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

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

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

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

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

这位兄弟，提出了很多想法和我这里团队开发的平台十分相像，我们的平台名称就叫快速开发平台 (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和完整的数据源的支持。在这基础上实现诸如工作流，规则引擎等等一系列的子系统拿就不是什么难事。而在这些基础架构上实现的项目，甚至产品也会有很强的生命力。

乘这个机会，我将前段时间总结衡量一个真正优秀构件平台的标准成立如下，以便各位有兴趣者参与评价：

灵活性：灵活性是可维护性和可扩展性的集中体现，基于组件的架构实现完全松耦合，各层之间真正彻底解耦 。

快速性：过分灵活就造成异常复杂(one size fit all)，导致开发效率降低，一个好的框架必须能够适用快速开发。

可伸缩性：没有一个固定解决方案适合大中小所有规模系统，但是小型系统的架构必须将来能够平滑过渡到大型系统，而不是推倒重来。

透明性：一个框架不能对开发者限制太多，也不能将开发者封装在一个黑盒子中，应该可以让开发者越过该框架 *** 作该框架力所不能及的功能。

良好性能：该框架要提供缓存或池功能提升性能，同时框架本身也必须提高性能，不能因为采取新技术而忽略性能要求。

状态管理：状态是业务逻辑中主要 *** 作对象，是等同于数据库的重要概念，一个框架应该提供领域模型的Session状态管理。

开发流程模板化：由于一个功能需要跨越J2EE多层结构，容易造成开发思路和管理混乱，这就要求框架架构适合规模化批量生产。

遵循OOA/OOD/OOP等设计原则，不能变相以数据库或传统过程语言思维替代OO。

总结

以上是内存溢出为你收集整理的讨论：想做一个快速业务构件平台不是那么简单，谈谈你的看法全部内容，希望文章能够帮你解决讨论：想做一个快速业务构件平台不是那么简单，谈谈你的看法所遇到的程序开发问题。

如果觉得内存溢出网站内容还不错，欢迎将内存溢出网站推荐给程序员好友。