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

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

评论

42 楼 allaneiaaa 2008-08-26  

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

41 楼 xingqiliudehuanghun 2008-08-26  

看到这篇文章真的百感交集，论资历来讲我只是个刚毕业的学生可能对开发框架评论显得狂妄了些。但是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
算了不说了，说起来就没完了

40 楼 惊鸿逝水 2008-08-26  

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

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

39 楼 pconline900 2008-08-26  

lszwycn 写道

pconline900 写道

seemoon 写道

很不错了，有点ror的味道了。另外有没有考虑一些convention的问题？这比较细节化了，也就是说，生成的代码到实际可用有多少距离，又比如界面要完全另做，如何实现？

界面完全定做很容易的，根据新的UI重新定义一套模板文件就OK了，只要你的元数据模型保持稳定就没有问题

想问一下页面文件和配置文件用的是什么代码生成引擎呢，不能也是jet吧

模板引擎可以产生任何文本文件，properties xml  jsp php aspx c# sql.......都没有问题

38 楼 longlongriver 2008-08-26  

seemoon 写道

很不错了，有点ror的味道了。另外有没有考虑一些convention的问题？这比较细节化了，也就是说，生成的代码到实际可用有多少距离，又比如界面要完全另做，如何实现？

初始代码是依据模板生成的，目前我们用的模板都是调测过的，如果不加自己的特殊业务代码的话，直接编译后就可以跑了，所有的配置文件都是自动生成的，只需要将生成的spring和struts的配置文件手工注册到web.xml和总applicationContext.xml文件中就可以了
另外，我们的代码生成器并不和IDE帮定（流程性应用设计除外），实际上生成代码后，就和它再没有关系了，你想怎么改就怎么改，界面完全另做你既可以直接改页面文件，因为后台的DAO和Server、Action都是通用的（这些代码你也可以自己改），也可以根据别的模板来再次生成，还是那句话，想改哪就改哪！
不过用平台开发之前还是需要一个培训的过程的，这也是必须的，我们对内有个80页左右的文档，一般一个普通程序员（知道struts、spring、hibernate）3天左右的时间可以熟悉整套平台构架并熟练开发，但如果想做到熟练使用流程设计器来做流程性应用的话，可能需要更长的时间，毕竟工作流的一些设计模型比较抽象，要说清楚的话，我估计又要单开个专题了，呵呵。。。

37 楼 cdxuyi 2008-08-26  

西安协同   呵呵 我见识过了  专门做工作流 这块比eos 的工作流 不在一个级别
估计楼上说eos 的 基本没用过 eos工作流 说单个代码看 eos 不算什么 一个软件产品 不就是承载了开发思想嘛 至于代码 单个看没意义 ，至于 eos中的基于web的流程定制平台 ，没见识过其它的了

36 楼 lszwycn 2008-08-26  

pconline900 写道

seemoon 写道

很不错了，有点ror的味道了。另外有没有考虑一些convention的问题？这比较细节化了，也就是说，生成的代码到实际可用有多少距离，又比如界面要完全另做，如何实现？

界面完全定做很容易的，根据新的UI重新定义一套模板文件就OK了，只要你的元数据模型保持稳定就没有问题

想问一下页面文件和配置文件用的是什么代码生成引擎呢，不能也是jet吧

35 楼 longlongriver 2008-08-26  

cdxuyi 写道

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

国内工作流引擎做的最好的应该是西安协同和杭州信雅达。ｅｏｓ可能还排不上前十吧！就我知道的，上海比ＥＯＳ的流程做的好的就有好几家，比如东兰...
工作流这东西应该是Ｊ２ＥＥ体系中最核心的东西了，ＥＡＩ、ＥＳＢ、ＢＰＭ无比牵涉到它，我之前这块的选型花了不少功夫，原来计划是用开源的ｊｂｐｍ，但它的ｓｔｕｄｉｏ及ＦｏｒｍＤｅｓｉｇｎｅｒ都不满意，最后还是推翻了，重新用了商用产品，呵呵！

34 楼 pconline900 2008-08-26  

seemoon 写道

很不错了，有点ror的味道了。另外有没有考虑一些convention的问题？这比较细节化了，也就是说，生成的代码到实际可用有多少距离，又比如界面要完全另做，如何实现？

界面完全定做很容易的，根据新的UI重新定义一套模板文件就OK了，只要你的元数据模型保持稳定就没有问题

33 楼 pconline900 2008-08-26  

<div class='quote_title'>badqiu 写道</div>
<div class='quote_div'>
<div class='quote_title'>longlongriver 写道</div>
<div class='quote_div'>
<div class='quote_title'>pconline900 写道</div>
<div class='quote_div'>楼主没有考虑到使用velocity不支持多次代码生成么，生成代码后开发人员修改了代码（这个肯定不可避免的），下次领域模型修改重新生成代码，就会覆盖开发人员的工作。这个问题不解决，工具就难以适应变化，你的代码永远只能生成一次，也后若业务需求修改，领域模型不断变化，以后的代码工作就只能靠人工写代码的方式支持了,这就要求开发人员很熟悉你的目标代码框架，代码之间的关系等等，知道该修改哪些代码或者配置文件。<br/><br/><br/>偶之前也做过类似的工具，基于MDA的思想，实现从PIM到PSM的转换。目标代码是JSF+Spring+Hiberate的，包括所有的页面 代码和配置文件等，选择模板引擎的时候也比较过velocity，最终由于它不支持代码反复生成给否决了。最后采用了JET+JMerge的方式，可以通过代码中特定注释的方式来识别是否需要覆盖目标代码，生成出来的代码可以由开发人员反复发修改反复生成，而不会丢失内容。<br/>建议楼主改版的时候可以考虑JET JMerge组合的方式。<br/><br/>建模的时候元数据模型参考了普元和楼上平台的元数据模型内容，采用Eclipse EMF进行建模，抽象了一套pim. SWT+JFace做工具的界面，基于Eclipse平台做了一个Eclipse的代码自动生成插件，可以直接产生完整的Eclipse工程。<br/><br/>可扩展性方面，插件还对外提供了扩展的Extention point，可以供第三方基于我们的插件开发新的插件，以适合不同技术的项目(如struts+ibatis)等。<br/><br/>工具再代码生成这一块和普元的Eclipse插件很类似，呵呵，开发中项目50%以上的代码都可以自动生成，效果还很不错。<br/><br/><br/>前面一位老兄写的三点基本上都能支持<br/>-----------------------<br/>惊鸿逝水 写道<br/>业务流程设计也不是什么新东西，关键是能定义一个好的业务流程Schema,拖拽爱怎么实现都行。 <br/>平台级的代码生成器，需要考虑： <br/>1、正向向导生成代码 <br/><span style='color: #ff0000;'>支持</span><br/>2、代码逆向生成向导<br/><span style='color: #ff0000;'>使用了Jmerge，所以支持 </span><br/>3、必要的编译检查。 <br/><span style='color: #ff0000;'>由于是Eclipse插件，自动产生的J2EE工程，会自动编译，所以支持</span><br/><br/>以上不是一个简单模板可以实现</div>
<p> </p>
<p>我不是很清楚“velocity不支持多次代码生成”是什么意思？用代码生成器第一次基于数据库元模型生成代码的时候，我们一般指定生成到项目开发路径（IDE）中，这不会对之前已经生成的别的实体的代码产生任何影响，如果针对已生成过代码的数据库表需要再次生成的话，可以在代码生成器中指定别的“项目路径”把新的代码指定到别的地方，然后再进行人工合并。</p>
<p>当然，利用平台进行开发的人员需要清楚生成的代码格式，因为针对特殊的业务逻辑是需要在此基础上进行修改的，我们不会像EOS那样去试图隔离程序员和代码，毕竟来说，代码还是最灵活的。</p>
<p>针对楼上的改版建议，我个人很感谢，但对于我们这种规模的团队来说，花大力气去将其做的大而全并不是我们的目标，花几个月做出这套东西对我们来说已经达到目的了，够用就行！写这篇文章的目的也是想将平台开发的一些经验和大家分享</p>
<p>最后说一点：我们的平台和东方易维的很类似，他们有的我们都有，如果大家对东方易维的产品有了解的话，可以做个比较</p>
</div>
<p><br/>pconline900 的合并这部分没有必要搞的这么复杂,代码生成只是初始时生成一个基础结构文件,后续在此基础上增加业务逻辑代码,字段的增加可手工修改代码即可.</p>
<p>而我个人很厌恶的一点就是很多平台妄图将程序员与代码隔离,全部傻瓜式的,编写配置文件就可以实现某些功能,但这种做法又没有代码灵活.而且平台实现复杂.</p>
<p>而使用这种平台的更加郁闷,完全不了解平台,只知道使用这种工具.</p>
<p> </p>
</div>
<p><br/>合并部分其实很简单，定义一个Jmerge的合并规则文件就搞定了，呵呵</p>
<p> </p>

32 楼 pconline900 2008-08-26  

longlongriver 写道

楼上的很有科诺ＫＡ-2平台的感觉，不同的是你的是以数据库驱动的，而且生成器是基于ｅｃｉｌｉｐｓｅ的插件来设计的。
我以前也用过ＫＡ－２，我的东东在权限这块除了ｊｇｕａｒｄ外，也借鉴了很多它的权限设计的思想。
另外问一下，不知道楼上是怎么解决你的流程性应用这块的需求？

向导连接数据库生成是主要的方式，另外也提供了自己用上面的模型编辑器重新创建一个数据模型的功能，然后根据这个模型生成代码，这种方式可以不用连接数据库。

流程性应用方面使用的Jboss Jbpm

31 楼 jmszhang 2008-08-26  

magicdoom 写道

呵呵  那个工作流引擎的截图看起来好熟悉

X.Y.D

30 楼 longlongriver 2008-08-26  

楼上的很有科诺ＫＡ-2平台的感觉，不同的是你的是以数据库驱动的，而且生成器是基于ｅｃｉｌｉｐｓｅ的插件来设计的。
我以前也用过ＫＡ－２，我的东东在权限这块除了ｊｇｕａｒｄ外，也借鉴了很多它的权限设计的思想。
另外问一下，不知道楼上是怎么解决你的流程性应用这块的需求？

29 楼 pconline900 2008-08-26  

<p>继续贴图 <br/><br/>这里设置页面查询区域的数据，也就是页面上面的查询输入区域</p>
<p> <img src='../../../../../../upload/picture/pic/20601/9b39b285-c09b-3ff7-b1c9-b14404280108.jpg' alt=''/> </p>
<p>设置模型文件的编码等信息</p>
<p><img src='../../../../../../upload/picture/pic/20605/8eb4c57e-b416-3a60-8edc-81bcffd0b2a1.jpg' alt=''/> </p>
<p>若有需要，可以设置一些选项信息，包括代码模板目录，代码合并规则，以及目标代码类别</p>
<p> </p>
<p><img src='http://www.iteye.com/upload/picture/pic/20611/d1621a1b-1e4f-3509-81a2-9586e0263b03.jpg?1219728178' alt='D1621a1b-1e4f-3509-81a2-9586e0263b03'/></p>
<p>完成后产生的Java工程，包括所有的配置文件 Java代码 JSP页面 数据模型文件等等</p>
<p><img class='magplus' title='点击查看原始大小图片' src='../../../../../../upload/picture/pic/20607/ece32116-34cd-356f-ac75-b7cd53c1fae5.jpg' height='497' alt='' width='700'/></p>
<p> </p>
<p>数据模型编辑器，可以反复修改数据模型，修改后可以更新全部代码，也可以选择更新部分代码</p>
<p>由于使用了Jmerge，之前产生的代码就算开发人员修改了很多，再次产生也不会覆盖，也不需要开发人员拿几次生成代码手工合并，呵呵</p>
<p><img class='magplus' title='点击查看原始大小图片' src='../../../../../../upload/picture/pic/20609/5a73ca1b-1460-340e-a4f2-6bdc64ff3a01.jpg' height='605' alt='' width='700'/></p>
<p> </p>
<p> </p>
<p> </p>
<p> </p>
<p> 最终产生的代码就是一个完整的功能块，可以直接发布到tomcat上运行，界面和楼主的类似，包括列表 增 删 改 查询等几个页面，页面字段的校验，字段的显示样式(selectbox checkbox等等)也都具备了，基本上很少修改，对UI风格不满意可以引入不同风格的代码模板就Ok了</p>
<p> </p>

28 楼 pconline900 2008-08-26  

<p>我也来贴一下我的这个快速开发工具的图吧，欢迎拍砖 </p>
<p> </p>
<p>新建自定义的工程<br/></p>
<p> <img src='http://www.iteye.com/upload/picture/pic/20587/c811041d-d809-374e-88c3-3d3c16cc3a5f.jpg' alt=''/> </p>
<p> </p>
<p>选择数据来源</p>
<p><img src='http://www.iteye.com/upload/picture/pic/20589/4c57702c-9595-3b87-87fc-9826086eef6a.jpg' alt=''/> </p>
<p> </p>
<p><img src='http://www.iteye.com/upload/picture/pic/20591/b41a38ac-6059-3da6-b16c-437ac09fd409.jpg' alt=''/> </p>
<p> </p>
<p>测试数据连接</p>
<p><img src='http://www.iteye.com/upload/picture/pic/20593/0c26fbb2-60ef-3399-8643-3f2cb82d1acd.jpg' alt=''/> </p>
<p> </p>
<p>选择数据模型及数据字典，可以选择多个</p>
<p><img src='http://www.iteye.com/upload/picture/pic/20595/f001fced-f3b6-354a-9766-a53c6138c65d.jpg' alt=''/> </p>
<p>可以选择修改模型字段的属性</p>
<p> </p>
<p><img src='http://www.iteye.com/upload/picture/pic/20597/86216e15-a167-3023-a8bb-61a6365a4688.jpg' alt=''/> </p>
<p>设置视图模型以及显示相关属性，支持定义正则表达式校验 js校验 定义页面元素为Text Select RadioBox等类型，若为Select RadioBox，可以选择数据字典</p>
<p> </p>
<p><img src='http://www.iteye.com/upload/picture/pic/20599/1019e0e1-a4f7-36a6-9b93-25dc7b7172c9.jpg' alt=''/> </p>
<p>数据字典选择</p>
<p> </p>
<p><img src='http://www.iteye.com/upload/picture/pic/20603/71ee79f4-6df7-3a37-be0a-757055943029.jpg' alt=''/> </p>
<p> </p>

27 楼 seemoon 2008-08-26  

很不错了，有点ror的味道了。另外有没有考虑一些convention的问题？这比较细节化了，也就是说，生成的代码到实际可用有多少距离，又比如界面要完全另做，如何实现？

26 楼 wangdi 2008-08-26  

lszwycn 写道

wangdi 写道

cdxuyi 写道

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

只想说两个字：汗………………

呵呵，当时研究eos的时候我们得出的一个结论就是eos扩展性太差，自己搞一套标准，一般不敢绑在他上面，毕竟eos不是ibm
不过作为一个eclipse plugin developer，还是很推崇eos studio的

eos是一个还算可以的软件，毕竟包含了那么多东西，但是还远不到承载什么思想，无出其右的说法，我估计啊，eos的市场人员都不敢冒这样的话处理。。怕被打死。。。其实他们的宣传已经够夸大的了。。

25 楼 lszwycn 2008-08-26  

pconline900 写道

楼主没有考虑到使用velocity不支持多次代码生成么，生成代码后开发人员修改了代码（这个肯定不可避免的），下次领域模型修改重新生成代码，就会覆盖开发人员的工作。这个问题不解决，工具就难以适应变化，你的代码永远只能生成一次，也后若业务需求修改，领域模型不断变化，以后的代码工作就只能靠人工写代码的方式支持了,这就要求开发人员很熟悉你的目标代码框架，代码之间的关系等等，知道该修改哪些代码或者配置文件。


偶之前也做过类似的工具，基于MDA的思想，实现从PIM到PSM的转换。目标代码是JSF+Spring+Hiberate的，包括所有的页面 代码和配置文件等，选择模板引擎的时候也比较过velocity，最终由于它不支持代码反复生成给否决了。最后采用了JET+JMerge的方式，可以通过代码中特定注释的方式来识别是否需要覆盖目标代码，生成出来的代码可以由开发人员反复发修改反复生成，而不会丢失内容。
建议楼主改版的时候可以考虑JET JMerge组合的方式。

建模的时候元数据模型参考了普元和楼上平台的元数据模型内容，采用Eclipse EMF进行建模，抽象了一套pim.  SWT+JFace做工具的界面，基于Eclipse平台做了一个Eclipse的代码自动生成插件，可以直接产生完整的Eclipse工程。

可扩展性方面，插件还对外提供了扩展的Extention point，可以供第三方基于我们的插件开发新的插件，以适合不同技术的项目(如struts+ibatis)等。

工具再代码生成这一块和普元的Eclipse插件很类似，呵呵，开发中项目50%以上的代码都可以自动生成，效果还很不错。


前面一位老兄写的三点基本上都能支持
-----------------------
惊鸿逝水 写道
业务流程设计也不是什么新东西，关键是能定义一个好的业务流程Schema,拖拽爱怎么实现都行。
平台级的代码生成器，需要考虑：
1、正向向导生成代码
支持
2、代码逆向生成向导
使用了Jmerge，所以支持
3、必要的编译检查。
由于是Eclipse插件，自动产生的J2EE工程，会自动编译，所以支持

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

比较感兴趣这个，能详细说说么

24 楼 lszwycn 2008-08-26  

wangdi 写道

cdxuyi 写道

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

只想说两个字：汗………………

呵呵，当时研究eos的时候我们得出的一个结论就是eos扩展性太差，自己搞一套标准，一般不敢绑在他上面，毕竟eos不是ibm
不过作为一个eclipse plugin developer，还是很推崇eos studio的

23 楼 wangdi 2008-08-26  

cdxuyi 写道

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

只想说两个字：汗………………