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

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

评论

102 楼 findhappy7 2009-07-21  

楼主，，我和你的方式不一样，，你选择忘记，我选择参考，，学习他们多年的经验，别人走了这么多年的道路，对应软件结构层次的划分，模型的抽取，这些是最最宝贵的，这些都是他们多年收集客户反馈再改良后的精华，应该吸取，当吸取了这些经验后，再进行消化，提升，从而形成更新一轮的理念。
这个是我们参考的作品，http://www.iteye.com/topic/421336 ，谢谢圈点

101 楼 iaimstar 2009-06-23  

代码隔离＋断网是提高程序员效率的最好办法之一
（但是程序员本身会觉得很悲情，很不人道，很没有自由度其实对公司来讲，效率＋效益就是王道）

100 楼 dreamlakyxy 2009-06-23  

longlongriver 写道

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

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

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

有demo或试用没？

99 楼 dreamlakyxy 2009-06-23  

funnywiser 写道

制作这种开发平台关键还是看你的最终目标，如果只是通过模板生成一个通用的代码，那总的来说还是一个代码生成工具。
而真正做一个开发平台，是不应该在对其生成的代码在做手工修改的。可以采用接口等方式，新作一些代码来扩展，而不能对生成的代码进行修改。
做到了这一点，才能真正保证开发的效率，而不需要去考虑反向等问题。
我们也做了快速开发平台，业务逻辑层和数据库层都已经不需要关心代码了，全部可以配置实现。
页面层，我们是根据模板来生成代码，当然生成的代码也是不需要修改的。

大牛很多。不过我就不信你业务逻辑可以全部配置实现，要么就是你没做过复杂的业务逻辑，就是简单的增删查改。

98 楼 thinke365 2009-06-23  

惊鸿逝水 写道

采用JET引擎是基于Eclipse平台开发的通用做法。

楼主的代码生成器作为平台级的东西是没有什么亮点，只做工具不做平台太可惜了
所谓将“程序员与代码隔离，全部傻瓜式的,编写配置文件就可以实现某些功能”
代码隔离不是剥夺写代码的权利，这也是将工具做到极致后，形成一套完整的编程模型的做法。即便你们现在的工具还没做到这样，但方向也是如此！

呵呵，代码隔离，很有创意啊。。。

97 楼 jacky6024 2009-06-22  

EOS rubbish!!!!

96 楼 longlongriver 2009-05-15  

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

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

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

95 楼 jzcjy 2009-05-14  

有一套适合自己企业应用的架构，可以大大提高开发的效率，降低维护的成本。

94 楼 kjj 2009-05-03  

让程序员更白痴的平台!!

93 楼 funnywiser 2009-05-02  

制作这种开发平台关键还是看你的最终目标，如果只是通过模板生成一个通用的代码，那总的来说还是一个代码生成工具。
而真正做一个开发平台，是不应该在对其生成的代码在做手工修改的。可以采用接口等方式，新作一些代码来扩展，而不能对生成的代码进行修改。
做到了这一点，才能真正保证开发的效率，而不需要去考虑反向等问题。
我们也做了快速开发平台，业务逻辑层和数据库层都已经不需要关心代码了，全部可以配置实现。
页面层，我们是根据模板来生成代码，当然生成的代码也是不需要修改的。

92 楼 wangjian3q 2008-11-03  

请问楼主 怎么没有下载的地方呢？

91 楼 longlongriver 2008-10-27  

<div class='quote_title'>ayu_sh 写道</div>
<div class='quote_div'>
<p>看了各位的评论，我也贴一个系统的截图</p>
<p>从以下<a href='http://pp.sohu.com/photoview-236300986-21452073.html' target='_blank'>地址</a>去看吧，sohu博客限制了图片的显示</p>
<p> </p>
<p>一个配置式的应用系统，可以配置表、页面、菜单</p>
<p> </p>
</div>
<p>呵呵，和obpm很像！</p>
<p>但完全隔离代码，完全基于配置式的系统在性能和灵活性上受到的限制更大，可扩展性有限啊！</p>

90 楼 srdrm 2008-10-20  

我同意某一楼说的, 如果单是为代码生成器搞一套GUI, 确实是麻烦了

89 楼 baozhengw 2008-09-28  

请参考一下OpenJWeb:http://blog.csdn.net/baozhengw/archive/2008/06/22/2575052.aspx ,在MVC开发模式中,原来需要程序员建表,写实体类.hibernate映射文件,配置spring bean的xml,action类,bo类,DAO类尤其是页面都需要程序员手工写,一般一个简单的模块也需要2天开发时间,而openJWeb平台可以在定义好数据库结构后,自动生成各层的代码及列表和编辑页面,列表页面自动带排序,跨数据库分页,条件查询等,不需要程序员写一行代码,而且生成过程中可以使用ANT API自动编译class,非常方便,比国外的appfuse要好

88 楼 雁行 2008-09-17  

混人堆里，观摩学习一下~
倒也真看到牛人啊，口气都不一般。
EOS的确很庞大，不过，我对他们的软件构件的开发方式还是很向往的。
软件开发过程中，重复性的工作的确太多了。

87 楼 b0r0j0 2008-09-09  

很巧，6月份的时候，我也写了一个和楼主一样的东西（不过没有GUI），我也来谈谈感想。

>>>> 背景：

我此次参与的项目，数据库设计的表有几百个（100～200），重新开发，早期我们选用的是Spring/Hibernate/DWR的框架，因为应用过很多次了，整体上使用还是很流畅的，对于普通的业务表需要写很多POJO,Service,DWR Action,JS,HTML。

差不多是项目做到一半的时候，我才产生了这个念头，因为有一天觉得MyEclipse生成的hbm实在是非常不好用，就想自己生成一个hbm，很快弄好了，从而考虑把整个工程全部生成，所以就动手了，做下来没有几天工夫，并整理成一个可以适合其它多层模型框架的B/S快速生成器的包（现在只是在企业内部用）。

我所在的企业是一家内地的中小企业，就软件部来说，没有几个实际人手，我即是项目经理、又是技术负责人、分析需求、设计数据库、设计架构、风格设计等等都要自己来整体的考虑。我们接的Case很多都是一个个工程（非产品化），所以从底层数据库建模开始，我可以自由的设计，尽量的复合第三范式，尽量适应自己的框架。

>>>> 效果：

开发好这个以后，自己的开发速度实在是快了不少，特别是有些新增加的表，让程序自动生成，实在是一种非常爽的快感，1，2秒就把普通的增、删、查、改、显示就全部生成好了，提升了很多开发效率，并且也避免了手工编写的错误几率。看上去很像自己一个人写的整个工程。命名、注释、风格整齐一致，看起来非常的舒服。

支持，配置调整底层数据库的适应类型及其它的类包等等的设置。

>>>> 评价：

我是非常喜欢这样的东西的，在我这个环境下，人员不多的团队，想加强自身的战斗力，必须有一些装备，有了这个你可以不需要考虑更多的情况自己就上了。

但是使用前，不要着急就全部重新生成，应该考虑哪些可以重用的问题，如果代码及功能模块本身可以重用，那么直接用好了，重用是软件人员应该最重要考虑的问题。
真的产品化的软件应该不会用这个，但是对于单兵作战的朋友，可以考虑一下，大胆的构建一个得心应手的工具。

在之前我就听说了普元的构件，并且老1建议我用这个构件来开发，因为我几乎没有时间去关注这个构件，我也没有用过，下载下来试试，看上去比较麻烦，担心后面很多因素都不可控制，所以我直接废掉了使用它来构建本次项目的计划。

但是我做的顶多是初级模型，在逆向工程、结合建模工具，特别是从维护、修改上很难做到不去动代码，再生成一次。如果生成了一次，但后期重新调整了底层数据库，那则是很别扭的一件事情，因为之前调整过的代码不会自动带上去，至少现在没有那么多精力去丰富这个工具成可以支持修改的。

初此之外，我花了总共几天的时间，自己手写了一个类似Spring IOC和Hibernate的ORM的简单框架，用了仅仅6个类，不再需要那么多的lib包，而且所有的东西都变得可控了，用起来还是真的很好用。虽然在实现Hibernate上有些困难，但都客服了，不求很全，但求最实际的用。

我建议大家自己去建一些自己喜欢的工具，按着自己的经验走，不要被高手误导了，因为某些高水平的人，着眼太高了，是的的确确，不适合自己。

86 楼 aaa_star 2008-09-05  

个人感觉上述一些代码工具/平台所生成的代码框架和目前的soa思路背道而驰,生成的代码能否被构建soa架构风格的应用所用都不好说，至于说根据设置反复生成代码就更不可能了。
当然上述话是在肯定后期应用应采取soa方式构建的基础上，但，我确实认为soa是未来一段时间内的首选架构风格

85 楼 hetylei 2008-09-05  

hongsoft 写道

hongsoft 写道

hetylei 写道

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

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

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

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

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

哦 ，对不起 先前卖给您的面包5.3实际是石灰做的，我们面包6.0才是真正“面”包

84 楼 jarchitect 2008-09-04  

erichua 写道

同意！普元的东东充其量就是一个变相的appfuse。主动权要掌握在自己手里，一定要构建自己的架构

和大多数的架构师一样，掌握了熟悉的开源的框架之后，就会慢慢懒惰起来。
对新的、别人认为优秀的技术、产品，免不了滋生一种抵制的思想。

在这里引用一下比尔·盖茨的自我总结：
“所有这些事情都可能使你懒惰，让你觉得无所不知，让你觉得自己比其他人聪明，而这总会导致严重的错误。”即使是最大的IBM公司，也错过了许多关键的事情。“我们必须学习新事物。”

人如企业，要持续不断的提高，也应该有持续的热情去学习新的开源项目，
新的商业产品，新的开发方式、管理思想。

如果有做过深入研究，给出具体技术的比较，这样的帖子相信会广受欢迎！
如果泛泛而论，就显得过于草率，没有说服力。

83 楼 erichua 2008-09-04  

同意！普元的东东充其量就是一个变相的appfuse。主动权要掌握在自己手里，一定要构建自己的架构