忘掉普元EOS、构建自己的企业级快速应用开发平台

希望这篇文章能够对那些正在或即将开发自己团队的J2EE应用快速开发平台的个人或公司能有所启发！    

      像EOS这样动辄几十上百万的平台不是每个公司都愿意花钱去买的！因此构建一套穷人级的企业快速开发平台成了很多团队的首选，而对于小团队来说，构建一套自己可以维护的开发平台才是最重要的。下面，我将以我的平台的开发过程为例来详细解析这个过程！  

“如果能把项目中大量的代码编写工作变得轻松，是多好的一件事!  "

        在使用了AppFuse之后，我有个想法，能不能利用velocity这个优秀的模板引擎，用一种更加直观的模式，把开发项目中的重复代码让它自动生成， 生成之后的基础代码，按照实际的需求稍作修改便可以运行，极大的提高工作效率。这样的话，程序员就可以从大量的重复劳动中解放出来，将精力更多的投入到业 务分析及学习中。

        这个想法一直在我的脑海里横亘不去，尤其在做了大量的重复模块后，深刻体会了重复Coding的那种浪费生命的痛苦后，这种冲动尤为强烈。

         离开旧公司，到了新公司之后，由于职位和公司定位的不同，让我有时间开始把快速开发平台和自动代码生成器的开发真正的摆上开发日程上了。

          第一步 ，自动代码生成器生成 的是业务模块，那么底层必须有一套框架能够为它提供支撑，而且这套基础框架要足够灵活，并且和单个模块的耦合性要比较弱。要解耦模块之间的联系，势必要用 到MVC分层设计。感谢Java的开放性，使它有这么许许多多的MVC框架可以使用。我采用的当然是目前最流行的 SSH（Struts＋Spring＋Hibernate）的组合（以前项目一直在用，也有些成熟的积累），花了三个月的时间，通过一个项目的实际应用来 使这个框架基本成型。其目前功能包括：

        1：灵活完善的权限管理功能（包括用户管理、角色管理、组织机构管理、资源管理、资源角色映射管理...）。原来计划采用开源的JGuard来托管这部分 的功能，因为一些特殊的原因放弃了（考虑要和工作流引擎的权限部分做集成），只采用了其权限管理的一些设计思想。

        2：基于Spring的AOP实现的日志和权限管理（通过Spring的代理也将Struts的Action托管了，使的对Action的调用也能被 AOP侦测到），这样对每个功能的调用，如果需要日志纪录的话，之间将其配置到Spring的配置文件中就可以了。

        3：UI上实现了类似.NET的Validation验证，这点很重要，想必大家都深刻体会到利用JavaScript或Struts的验证机制来实现前端页面数据验证的痛苦了吧：），我们实现的功能如下图所示：

       

        4、多套UI风格样式。这个不是很必须，但是作为一套成功的系统，良好的用户体验也是必不可少的。

        5、支撑模块：2套报表引擎（一个是基于JasperReport实现的B/S版本报表；另外一个是类Excel的报表引擎），流程引擎（其实就我个人来看，工作流引擎才是这套系统的灵魂 ，有了它，所有流程性应用包括表单、业务流、权限都可以通过配置并结合Beanshell脚本来获得 ，以下是我们报表和流程设计器的一些截图：

 

 

工作流引擎截图

 

报表截图

 

        6、i18n的支持，由于我们有很多国外的客户，这块是必须的。

 

有了这个基础支撑平台之后，就可以开始着手开放我们的代码生成器了。

        第二步 ：开发代码生成器。 AppFuse基于Ant的自动代码生成模式让我深恶痛绝，究其原因，一句话－－“不够人性化”，我们做的首先必须考虑可用性，因此决定采用可视化的UI 模式。由于我用的是NetBean编辑器，做可视化的Swing开发不成问题（这点要感谢SUN啊，出了个和VB一样简单的IDE）。我实现的代码生成器 的界面如下：

  

 

怎么样？是不是够傻瓜化啊？呵呵，是个人都能用啊！

       从上面大家可以看到，我们这个代码生成器和Hibernate的POJO对象生成工具类似，也是基于数据库的模型来生成代码的，不同的是，我们生成的代码 范围更广，不仅包括了POJO对象暨相应的hbm.xml文件，另外还包括相应的DAO（Server层）、相应的Action、Form类、相关的 JSP文件（list页面、edit页面、Excel导出页面等等）、资源文件及相关的Struts和Spring的配置子文件（Struts和 Spring均支撑将配置拆分成多个配置，我们利用这种特性来减低模块之间的耦合性。）

        至于数据库模型的获得，可以利用JDBC的MetaData（元数据模型） 的功能来获得，我们目前维护了表的完整的主键、外键关系（父子表）

 第三步：配置模板。有了可视化的数据库表映射模型，也获得了数据库表及其主外键关系的详细信息，接下来当然是根据这些信息来生成代码了。这里我们用了强大的Velocity模板 技术，这样不仅可以灵活的处理复杂的表映射对象之间的关系，也能够灵活的进行变更升级。而且我们能够通过所获得的数据库模型，在页面上自动实现基于Javascript的数据验证“非空验证、字符长度验证、数字验证，日期验证”。

          呵呵，通过以上3个步骤的工作，我们的基础开发平台和自动代码生成器就大功告成了！目前我们生成的代码可以直接编译通过，通过简单的系统配置后，可以直接在服务器上跑！ 由于模板种类多，而且模板中自动实现的代码功能已经非常完善了，所以一些特殊的业务需求只需要在自动生成的代码基础上做简单修改就可以了！

         基础开发平台和代码生成器投入使用后，对我们项目开发的资源投入的改善是非常明细的，目前基于基础平台和代码生成器的配合，我们已经做了6、7个系统了，平均每个系统的 开发时间至少要比以前节约40％，有的项目甚至达到了80％以上（我们最高的一天，处理了40多个表的增、删、该、查的功能，及中文本地化）。而且，另外 很重要的一点，生成的代码无形中统一了程序员的设计风格，我们通过这套开发机制，能够最大限度的保证我们开发的系统质量，保证模块可以在不同系统之间的自 由迁移，最大限度的实现复用！在项目开发中节省出来的大量时间，也让我们可以去研究更多的开源中间件和系统，来增强我们的基础平台，从而形成一个良性的循 环！

 我们做了多套模板，能够针对单表操作，及父子表操作来自由组合搭配。以下就是我们系统的一些功能截图，除了中文化之外，基本上没有修改：

单表操作：

父子表关联操作：

 

 

================================================================

呵呵，这么长时间了，还有人关注这个帖子，谢谢大家的捧场了！
顺便通报一下我们平台目前的状况：
1、增加了Web Service接口功能，基于spring-xfire实现的，目前基于server这一层的所有接口，在代码生成器生成代码（或手工添加接口） 时，xfire会对其自动封装并对外暴露。并同时集成访问接口。程序员不用直接接触wsdl了（安全方面目前只是通过IP过滤来简单实现）。
   这样的话，同样基于平台的A、B两个独立系统，可以通过WebService进行相互调用，同时，从本地调用变更为webService调用不需要修改任何代码，只要修改配置文件的一行定义就可以了！
   这个应该算是我们平台的一个标志性的里程碑了吧！从一定意义上来说，这才真正成为一个开放的平台，算SOA化了，呵呵！

2、模板更加丰富了，基于工作流应用我们目前已经有了一套通用模式，可以和流程引擎进行无缝结合！针对流程应用的模板可以生成绝大部分引擎相关部 分的代码，程序员只需要修改流程定义模板的名称就可以了！同时针对一对多，一对一关系的模板进行了大量优化，能够适应更多的企业应用场景了！

  目前的平台还是主要针对开发人员，是企业应用快速开发 平台，我们后续规划将其和我们已经有的一套应用快速搭建 平台进行整合，以使其能够同时被业务人员和开发人员使用。简单业务就由业务人员通过搭建平台的可视化的流程和表单配置来实现，复杂业务再由技术人员通过开发平台来实现。
   最后再谈一下应用快速开发平台的定位吧，相信这也是大家最近争论的一个焦点，说有用的有之，说用处不大的也有之。我个人的观点是：只要你的平台够灵活，模 板够多、够复杂、兼容的业务场景越多，它就有用，而且很有用；反之，如果平台底层呆板，模板简单，它的用处就不大。至于其它的什么维护的便利性什么的我就 不再多说了，免得有吹嘘之嫌了，反正大家仁者见仁，智者见智！套用一句常话就是－－－寒天饮冰水，冷暖自知！
  我个人目前的工作重点已经转移到企业应用快速搭建（配置）平台上来，目前也有些心得，将其和应用快速开发平台的整合也颇有些成效，后续得空将续开些新博文，和大家共享，希望各位继续赏脸捧场！！！！

评论

82 楼 tenlon 2008-09-02  

hover1215 写道

eos 是典型中国人的软件。

犯的也是典型中国人的臭毛病。

矫枉过正。

但还跟着ibm，bea，非要和soa 拉上关系，跟着洋人屁股后面混。

最后也就落个吃洋人屁的下场。

SOA是销售们去谈论的， 和技术关系不大。

81 楼 hongsoft 2008-09-01  

hetylei 写道

认同sunwine 对 “平台”的正确理解。
1）平台 的确是用来限制 开发者的
2）平台绝对会有bug(软件都会有bug）
3） 性能问题我不知道有多严重？ 能否告诉我个人？ 我们对性能是比较看重的，也花了很大气力。

我们对SOA的思想，主要还是在 EOS6.0和BPS平台 上融入的。
希望6.0发布后，您试用看看。

就是说6.0以前的版本是纯忽悠了呗

没有人说过SOA才是唯一的真理吧？什么产品都是不断发展的。

不过想想这种问题和我的回复还真是无聊，以后不回复这种问题了。

80 楼 lendo.du 2008-09-01  

我个人觉得这种方式并不是以后的方向。IBM的那东西出了很久了。成了主流了吗？

以前中科大的校长给俺们上课的时候这样讲。要做什么首先参考国外，因为别人有经验。

这种东西IBM都推不走。就别指望一个EOS能有多大作为了。

并不觉得EOS这种方式有多大的影响。一个熟悉的程序员完成同样的工作。

在有前一个项目积累的情况下。也许效率更高。

软件工程最重要是对人讲的。除非电脑发展到人脑的阶段。否则这种方式都不会成为主流。

79 楼 hetylei 2008-09-01  

hongsoft 写道

sunwine 写道

对于EOS的评论有些还是不能赞同的。

1，EOS限制了灵活性，这不应该是个需要拿出来说的问题，既然你用平台，就肯定不能指望向你编代码一样的随心所欲。这就好比传统意义上的裁缝和流水线上的缝纫工的区别，你得遵守流水线的规则，完成自己范围内的工作。

2，EOS很多Bug，呵呵，应该不是瞎说，但这也不是你否定他的地方，软件就是这样，做出来总有问题，但只要用心去做，Bug都是可以很快消灭的东西。

3，EOS有许多不足、性能也不行，都是问题，但都不是问题，只要是可以解决的问题就不是问题，给普元半年时间一切都能够解决。

我们看待一个产品的角度更多应该看他的设计思想和其发展的方向，这最重要，EOS如果能够真正带来效率，而价格也能平民化些，还是很有前景的，过程中的问题都是可以解决的，只要重视。

我们作为普元的竞争对手，其实还是比较欣赏普元的，不为他的产品，而是他的坚持。在这条路上能够忍住寂寞持之以恒是很不容易的。

不过普元在SOA上的夸张的宣传和大量的投入却让人感觉有些莫名其妙，SOA不是灵丹妙药，且和EOS关系也不大，不知普元为何如此投入，把精力投入到EOS上也许会更好些。

认同sunwine 对 “平台”的正确理解。
1）平台 的确是用来限制 开发者的
2）平台绝对会有bug(软件都会有bug）
3） 性能问题我不知道有多严重？ 能否告诉我个人？ 我们对性能是比较看重的，也花了很大气力。

我们对SOA的思想，主要还是在 EOS6.0和BPS平台 上融入的。
希望6.0发布后，您试用看看。

就是说6.0以前的版本是纯忽悠了呗

78 楼 hongsoft 2008-08-31  

sunwine 写道

对于EOS的评论有些还是不能赞同的。

1，EOS限制了灵活性，这不应该是个需要拿出来说的问题，既然你用平台，就肯定不能指望向你编代码一样的随心所欲。这就好比传统意义上的裁缝和流水线上的缝纫工的区别，你得遵守流水线的规则，完成自己范围内的工作。

2，EOS很多Bug，呵呵，应该不是瞎说，但这也不是你否定他的地方，软件就是这样，做出来总有问题，但只要用心去做，Bug都是可以很快消灭的东西。

3，EOS有许多不足、性能也不行，都是问题，但都不是问题，只要是可以解决的问题就不是问题，给普元半年时间一切都能够解决。

我们看待一个产品的角度更多应该看他的设计思想和其发展的方向，这最重要，EOS如果能够真正带来效率，而价格也能平民化些，还是很有前景的，过程中的问题都是可以解决的，只要重视。

我们作为普元的竞争对手，其实还是比较欣赏普元的，不为他的产品，而是他的坚持。在这条路上能够忍住寂寞持之以恒是很不容易的。

不过普元在SOA上的夸张的宣传和大量的投入却让人感觉有些莫名其妙，SOA不是灵丹妙药，且和EOS关系也不大，不知普元为何如此投入，把精力投入到EOS上也许会更好些。

认同sunwine 对 “平台”的正确理解。
1）平台 的确是用来限制 开发者的
2）平台绝对会有bug(软件都会有bug）
3） 性能问题我不知道有多严重？ 能否告诉我个人？ 我们对性能是比较看重的，也花了很大气力。

我们对SOA的思想，主要还是在 EOS6.0和BPS平台 上融入的。
希望6.0发布后，您试用看看。

77 楼 hongsoft 2008-08-31  

jmszhang 写道

longlongriver 写道

cdxuyi 写道

eos 承载的是软件工程的思想 ，studio及工作流 ，无出其右

国内工作流引擎做的最好的应该是西安协同和杭州信雅达。

反对

cdxuyi好评西安协同和杭州信雅达，我个人猜测 是受到我 2004年 的“工作流大局势”文章的影响，呵呵。

那时我还不在 普元，那时 EOS工作流 基本还没有进入我的 “法眼”。

现在我对 杭州信雅达 的工作流 持 很一般意见，60分。

西安协同作为我们现在的竞争对手，我个人感觉，80分吧。

EOS工作流还可以，希望大家看看 EOS工作流6.0版。

76 楼 Godlikeme 2008-08-31  

在一个错误的问题上讨论一堆乱七八糟的事情。

75 楼 hetylei 2008-08-30  

呵呵

“国内SOA巨头”--普元 开始大力搞EOS培训了

还不便宜3天 ，1000/天

还有机会成为EOS认证程序员呢

搜下51JOB EOS相关职位 有50个之多呢

74 楼 jzcjy 2008-08-29  

longlongriver 写道

xingqiliudehuanghun 写道

用eos最大的感觉就像被戴上了枷锁一样，用代很容易实现的问题需要用一大堆的图形化组件来实现，难道这是进步吗？

EOS最大的问题是将辅助开发给做的太过了，它试图用大大小小的构件来替代人工coding，但这世上不可能存在一套固定的构件就能去描述所有的业务场景，不然也就没有语言存在的价值了，在这点上，我个人觉得普元对自己产品角色的定位有问题，他应该去做的只是辅助开发，而不是试图完全替代和隔离代码
一句话，业务是活的，语言是活的，构件是死的（至少是半死不活）  ：）

我们公司也是听过EOS的培训，的确是这样子，为什么实际的效果和宣传差距如此大？

73 楼 jzcjy 2008-08-29  

joachimz 写道

杭州信雅达的工作流接触过，感觉很一般。

不过，工作流发现国内的应用大家都比较关注签批，回退还有自由流这些Human Task的事情。

其实工作流的重点，应该是优化应用的架构，便于业务流程改造和系统整合吧。而这方面，需要遵循一些通用规范，一些大的厂商明显占有优势。

前几天看到锐道（dorado）和信雅达有一腿；

因为我也在寻找工作流；

72 楼 jzcjy 2008-08-29  

惊鸿逝水 写道

这种生成器太初级了，只能算工具级的

lz的意思是快速，是这个想法的初步实现，你意思是，你水平很高，搞出来高级版的了，谢谢，快SHOW一下！

71 楼 hetylei 2008-08-29  

引用

呵呵，badqiu，谢谢你的验证框架了，省了我不少功夫啊！另外看了你在google－code上的那些项目，很佩服你的创新精神，以后多多交流！

看了看 rapid-validation 确实不错 基本的验证都能满足了

70 楼 longlongriver 2008-08-28  

badqiu 写道

惊鸿逝水 写道

业务流程设计也不是什么新东西，关键是能定义一个好的业务流程Schema,拖拽爱怎么实现都行。
平台级的代码生成器，需要考虑：
1、正向向导生成代码
2、代码逆向生成向导
3、必要的编译检查。

以上不是一个简单模板可以实现

"逆向",服了,怎么生成? 基于Hibernate Model生成数据库表?
复杂化了,同学!!

另外在楼主的项目中又看到了我的表单验证框架的影子,

另外楼主可以看下我的项目,为代码生成器开发一套GUI,还是太麻烦了
http://code.google.com/p/rapid-framework

呵呵，badqiu，谢谢你的验证框架了，省了我不少功夫啊！另外看了你在google－code上的那些项目，很佩服你的创新精神，以后多多交流！

69 楼 yungerboy 2008-08-28  

长见识了。我现在也在开发一套通过xml配置与java注解生成增，删，改，列表组件。

68 楼 cdxuyi 2008-08-28  

我不信 现在的编码人员 不想跟着洋人屁股后面混 struts spring hibernate seam jbpm  那个是国人自己写的
相反 我挺佩服 普元的开创性 和坚持， 能跻身参与soa 标准，对中国本土软件企业本身是很难的事情。

67 楼 hover1215 2008-08-28  

eos 是典型中国人的软件。

犯的也是典型中国人的臭毛病。

矫枉过正。

但还跟着ibm，bea，非要和soa 拉上关系，跟着洋人屁股后面混。

最后也就落个吃洋人屁的下场。

66 楼 pconline900 2008-08-28  

longlongriver 写道

cdxuyi 写道

eos 的购买目标群 不是针对编写代码的人 而是项目管理人员 也就是 在2003年左右的时间 一个能把中国式工作流 做得如此快速 理解如此深入的 估计也只有普元 项目管理人员考虑的是如何快速开发 降低成本 快速应对需求变更 ，单从快速应变的角度 eos做到了。但eos为要做到这点的 也作出了牺牲，造成了和现实的面向对象的方法格格不入。编码人员反感严重。 这个也是普元即将修改的地方。对项目型的公司而言 自己开发维护一套平台 谈何容易。现在的任何框架 平台 不是也正式向这方面发展的嘛，让使用者多关注业务

呵呵，不管EOS的受众目标定位是什么，就我所接触到的事实是，最终用EOS的还是开发人员，这和楼上所谈的好像有些差距！
至于自己开发维护一套平台，如果一切自己从头构建的话，肯定成本高，也不现实，但J2EE体系最大的优势就在于有众多的开源中间件可供选择，完全不用重复发明轮子。我的文里已经说的很清楚了，这个平台除了工作流引擎之外（这个我会另外起个贴详细说说），其它所有的组件都是用开源产品来组装的，至于代码生成器，则是基于netbeans的RCP用了2周不到的时间自己写的。平台定型后，我们目前并没有专门的人员去维护它，但基于各个项目的反馈，平台依然能够获得不断的完善，我并没有觉得维护成本有多高，倒是基于这个平台，我们能够为开发人员节省下大量的开发时间和精力，投入到业务或其它领域的研究中，而且开放的平台也提高了技术人员研究技术的兴趣，热衷于去扩展它的功能，弥补不足。另外，出乎我的意料的是，自从平台上线之后，团队的精神面貌和以前有了很大的不同，项目也做的更加从容，大家都能进步，完全是一种良性循环的局面。

对，适合于公司的技术架构的工具就是最好的，何况这个工具开发工作量很小，偶前面发的这个工具也就是两个人一个月从概念到产品出来搞定的，还包括学习Eclipse插件、EMF、JET等技术的时间，最后统计代码量也就一万多行

EOS的失误就是太重量级了，什么都想涵盖，太理想化想解决所有的问题；自己做的代码生成工具是适合企业特点的，很轻量级别的工具，定位为开发辅助工具，所带来的效果是非常不错的。就类似于EJB和Spring的区别了

65 楼 longlongriver 2008-08-28  

cdxuyi 写道

eos 的购买目标群 不是针对编写代码的人 而是项目管理人员 也就是 在2003年左右的时间 一个能把中国式工作流 做得如此快速 理解如此深入的 估计也只有普元 项目管理人员考虑的是如何快速开发 降低成本 快速应对需求变更 ，单从快速应变的角度 eos做到了。但eos为要做到这点的 也作出了牺牲，造成了和现实的面向对象的方法格格不入。编码人员反感严重。 这个也是普元即将修改的地方。对项目型的公司而言 自己开发维护一套平台 谈何容易。现在的任何框架 平台 不是也正式向这方面发展的嘛，让使用者多关注业务

呵呵，不管EOS的受众目标定位是什么，就我所接触到的事实是，最终用EOS的还是开发人员，这和楼上所谈的好像有些差距！
至于自己开发维护一套平台，如果一切自己从头构建的话，肯定成本高，也不现实，但J2EE体系最大的优势就在于有众多的开源中间件可供选择，完全不用重复发明轮子。我的文里已经说的很清楚了，这个平台除了工作流引擎之外（这个我会另外起个贴详细说说），其它所有的组件都是用开源产品来组装的，至于代码生成器，则是基于netbeans的RCP用了2周不到的时间自己写的。平台定型后，我们目前并没有专门的人员去维护它，但基于各个项目的反馈，平台依然能够获得不断的完善，我并没有觉得维护成本有多高，倒是基于这个平台，我们能够为开发人员节省下大量的开发时间和精力，投入到业务或其它领域的研究中，而且开放的平台也提高了技术人员研究技术的兴趣，热衷于去扩展它的功能，弥补不足。另外，出乎我的意料的是，自从平台上线之后，团队的精神面貌和以前有了很大的不同，项目也做的更加从容，大家都能进步，完全是一种良性循环的局面。

64 楼 love_seam 2008-08-28  

cdxuyi 写道

eos 的购买目标群 不是针对编写代码的人 而是项目管理人员 也就是 在2003年左右的时间 一个能把中国式工作流 做得如此快速 理解如此深入的 估计也只有普元 项目管理人员考虑的是如何快速开发 降低成本 快速应对需求变更 ，单从快速应变的角度 eos做到了。但eos为要做到这点的 也作出了牺牲，造成了和现实的面向对象的方法格格不入。编码人员反感严重。 这个也是普元即将修改的地方。对项目型的公司而言 自己开发维护一套平台 谈何容易。现在的任何框架 平台 不是也正式向这方面发展的嘛，让使用者多关注业务

63 楼 love_seam 2008-08-28  

适合自己团队的才是最好的。