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

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

评论

62 楼 cdxuyi 2008-08-28  

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

61 楼 bennyparlo 2008-08-28  

大致看过楼主对业务构建平台的实现思想,其实对于家项目型公司来说,有这么个可能还算不上平台级产品的构建工具来讲已经完全足够了,毕竟主要目的在于能够给项目组提供个高效稳定能够满足项目中80%需求的工具即可.而对于eos这样的平台级商业产品来讲,其更大程度及意义还在于对soa以及构件化开发方法论的实践推广,套的帽子太高太大,而其适用领域也更偏向电信与金融行业.再者产品成本的投入过大,其中包括产品的lisence以及培训维护合同等.说实在话,花这么些成本也足以在公司内部立项,打造适合项目本身的构建平台,一劳永逸.如果产品实施成功甚至可以考虑向商业化方向发展.本人也长期从事与构建平台的研发及咨询工作,愿与楼主长期交流进步.

60 楼 sunwine 2008-08-27  

badqiu 应该理解错我所说配置的意思啦，如果手工去配置XML文件达到开发目的，这显然是愚蠢的。badqiu 其实可以看看我们的产品，有兴趣可以研究下，我们提供试用版本下载。

xingqiliudehuanghun 这个结论下得感觉有些早，EOS可能给你带来过痛苦，但建议不把这种感受扩大为广泛结论。

59 楼 xingqiliudehuanghun 2008-08-27  

用了eos以后我暂时得出两个结论：
    1.千万不要使用那些太花哨，看起来很傻瓜化的ide，那些东西十有八九是一个漂亮的陷阱，能给提供一些好用的类库足矣。
    2.傻瓜化的ide带给你的好处与它带给你的bug几乎一样多。
    3.对你的项目的开发进度起决定作用的是明确的需求和好的设计，而ide所起的作用与他们相比要小的多。

总结：花很高的价钱去买一个你所不了解的平台简直是自己给自己找麻烦

58 楼 longlongriver 2008-08-27  

woweiwokuang 写道

哈哈. 看到了这些, 感觉还是EasyJF团队的思想有点前沿. 上面讨论的功能,他们通过easyjweb+spring+JPA完全实现了. 什么零配置啊. velocity啊.  逆向生产表啊.  他们里面都有了.

一套完整的平台不仅仅只是用来提高实体的增删改查的开发效率，还需要对门户定制、流程性的配置应用、报表、日志监控、缓存、消息方面都要有完备的支持和综合考量的。

57 楼 woweiwokuang 2008-08-27  

哈哈. 看到了这些, 感觉还是EasyJF团队的思想有点前沿. 上面讨论的功能,他们通过easyjweb+spring+JPA完全实现了. 什么零配置啊. velocity啊.  逆向生产表啊.  他们里面都有了.

56 楼 badqiu 2008-08-27  

sunwine 写道

EOS在产品的最初规划上是有些问题的，粒度太小了，所以一个简单的东西都要画个图。这是个较大的问题。

但如果EOS定位在辅助开发上，那就是个IDE啦，这不是他的定位，我们无法否认业务的复杂性，但也并不意味着死的构件的就无法实现复杂业务，编程语言其实也是死的，只是他粒度小，层次低，所以可以构造出大量复杂业务。构件其实也一样，如果把握好粒度，和考虑复用灵活性，构件同样也能实现复杂业务逻辑。

EOS在粒度上是有问题的，但并不意味着构件复用快速开发不行，我们的产品和多年的切身体验其实一直在证明这种想法的可行性。

http://www.extract.com.cn:8855 这是一套完全通过组件复用开发实现的系统，没有Java代码，也没有JSP页面，完全配置开发。

构件、组件复用快速开发的可行性和灵活性其实并无大的问题，关键点是如何获得高质量的可复用组件，并提供一套稳定可靠的复用方式。

疏不知配置写多了比代码更难维护.而妄图用构件的方式来全部解决应用开发的复杂性，那就不用程序员了.
而对于配置文件，现在提倡的是零配置，所以现在类似rails的框架大行其道.

55 楼 sunwine 2008-08-27  

EOS在产品的最初规划上是有些问题的，粒度太小了，所以一个简单的东西都要画个图。这是个较大的问题。

但如果EOS定位在辅助开发上，那就是个IDE啦，这不是他的定位，我们无法否认业务的复杂性，但也并不意味着死的构件的就无法实现复杂业务，编程语言其实也是死的，只是他粒度小，层次低，所以可以构造出大量复杂业务。构件其实也一样，如果把握好粒度，和考虑复用灵活性，构件同样也能实现复杂业务逻辑。

EOS在粒度上是有问题的，但并不意味着构件复用快速开发不行，我们的产品和多年的切身体验其实一直在证明这种想法的可行性。

http://www.extract.com.cn:8855 这是一套完全通过组件复用开发实现的系统，没有Java代码，也没有JSP页面，完全配置开发。

构件、组件复用快速开发的可行性和灵活性其实并无大的问题，关键点是如何获得高质量的可复用组件，并提供一套稳定可靠的复用方式。

54 楼 hetylei 2008-08-27  

最可笑的是你拼一个带规则的字符串也要用构件来做

见过用流程图表现一个拼字符串的过程么?  eos:我能

如果你不想这样干，就得自己做一个构件：定义一个static类！

53 楼 longlongriver 2008-08-27  

xingqiliudehuanghun 写道

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

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

52 楼 xingqiliudehuanghun 2008-08-27  

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

51 楼 hetylei 2008-08-27  

看到几乎所有的人的角手架都是基于数据库生成的

搞一个简单的配置不好么

可以生成对应数据库的DDL
不用担心数据库兼容性的问题
POJO里再也看不到全是大写的命名

50 楼 lkjust08 2008-08-27  

个人认为很好，不知楼主是否可以共享呀。

49 楼 joachimz 2008-08-26  

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

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

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

48 楼 jmszhang 2008-08-26  

longlongriver 写道

cdxuyi 写道

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

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

反对

47 楼 lszwycn 2008-08-26  

sunwine 写道

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

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

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

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

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

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

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

呵呵，这个说的比较...
1.好像很多linux的开发人员一谈到linux和windows的优势的时候就说windows太死了，我们可以在linux上随心所欲，并且号称linux是给程序员用的操作系统，好像开发平台也是给开发人员用的，不知道是linux的哲学错了还是楼主错了，反正linux现在遍地开花了
2.确实我们不能因为一个软件有bug就全盘否定这个软件，问题是我们否定的是现在这个软件的不完善
3.别扯什么是问题又不是问题，如果按照这个逻辑，我写个hello world，如果加以时日，投入无限的时间、金钱，再把什么ms，ibm，google的开发人员全加上，相比也能够成为一个消灭了windows、linux 、mac os的超级nb的os的，可是这么想象有意思么

ps：我上面也说过，作为eclipse plugin developer，我是很欣赏eos studio的，但是都楼上的逻辑不敢苟同

46 楼 sunwine 2008-08-26  

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

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

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

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

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

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

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

45 楼 longlongriver 2008-08-26  

xingqiliudehuanghun 写道

看到这篇文章真的百感交集，论资历来讲我只是个刚毕业的学生可能对开发框架评论显得狂妄了些。但是eos5.5-eos5.6我们用了近一年了，其中的苦楚可能只有自己才能体会到。

eos被各位大牛夸的那么强大，可是有几个真正的用它来开发过呢？到头来还是哭了我们这些做代码的。正好趁这个机会发泄一下。

首先不能不说的是eos的bug了，以UIbug居多.如果你用他的单表向导生成一些逻辑，你在查询字段中输入一个单撇号，你会收获第一个bug，还有哪些是不是的fbrole的弹窗bug，菜单生成bug，形同虚设的单点登录功能，至于跨浏览器那就更别想了，所有的东西ieonly。而且奉劝大家最好不要使用它的模板生成jsp，里边的那些凌乱的js有时候会影响你的js文件的加载和js程序的运行。再有一点需要奉劝的就是使用eos操作数据库的时候千万要少用list和循环能让你的程序奇慢无比，因为需要从java对象转化成xml节点，所以如果你的数据库查询结果较大的话一定要分页，否则你的服务器很快就要down了，我们实验过一个2000行左右的查询结果基本上就可以把eos down掉。

还有就是自己手动把fbrole中的一些代码改一下，因为里边有个很低级的错误导致大量的数据库连接没有关掉
if(rs==null)
    rs.close();
    .....
把它改成
if(rs!=null)
    rs.close()
这个错误还是我们告诉的eos
算了不说了，说起来就没完了

同情！这就是开发人员无法掌控平台的后果。其实又何止一个EOS呢！当年我用IBM的WSAD、科诺的KA－2也是问题一堆，才有了自己做平台的想法，也算是被逼出来的吧，呵呵。。。

44 楼 cryolite 2008-08-26  

allaneiaaa 写道

代码自动生成的工具要本着中庸思想才好。 太简单设计了，达不到要求。太复杂太完美的设计了，那更完了，程序员都没饭碗了。所以不要太过于研究它，大概思想知道即可。重要的还是要在更高的一个层面塑造自己

什么逻辑。真讨厌这种高瞻远瞩提纲挈领的话，不像真正搞技术的人说的，你就忽悠吧

43 楼 sunwine 2008-08-26  

感觉代码生成技术还没有到成熟的时候，楼主的探索是有意义的，但对于企业级的项目来讲还是太弱了些，当然也不用和EOS比较，EOS不是代码生成型的快速开发平台，EOS是基于构建复用的平台，两样的，不过基于构建复用也是比较现实的快速开发实现技术。我们在这个方向上也已经投入了7,8年时间，还是很有感触的。

快速开发的本质无论是代码生成还是组件复用，都是对已有程序的复用，只是角度不同，但不建议尝试做代码生成角度的探索，代码本身是非常复杂的，你如何让他简单化？楼主的尝试其实是实现快速框架的生成，而不是代码的生成，一个简单的个人所得税算法，你如何快速生成代码？

如果不尝试使用市场现有的快速开发平台产品，也可以通过公司或团队的内部积累实现部分的快速开发，楼主的架构代码生成是一个方面，另一个重要方面其实是数据处理逻辑的积累，比如基本的表集数据运算逻辑，基本的日期计算逻辑，如果花些时间把一些常用的逻辑代码整理好，编译好，就可以在后续项目中实现快速复用。

其实每个工程师都知道复用的价值，但往往不容易进行积累，或没有兴趣，或项目太急切了，一直感觉每个软件公司只要条件允许其实应该成立一个基础架构部门，负责代码的整理和复用工作，其实这样的投入是很值得的，虽然表面上不创造价值。

有兴趣可以访问我们的产品，以组件复用实现快速开发，复用覆盖逻辑和展现，基本可以做到零编码开发，开发的效率也相当好。

http://www.extraction.com.cn