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

呵呵，看来文章的标题还是给大家造成一定的歧义了，其实我个人的意思是构建一套穷人级的企业快速开发平台，毕竟像EOS这样动辄几十万的平台不是每个公司都愿意花钱去买的！而且对于小团队来说，构建一套自己可以维护的开发平台才是最重要的。
另外，此平台真正的业务构建是基于流程引擎＋代码生成器来共同完成流程业务和非流程业务的快速开发的，针对这部分内容我已经重新修改文章，大家如果有兴趣，可以重新再浏览一遍，相信能减少一些理解上的歧义！

楼主没有考虑到使用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工程，会自动编译，所以支持

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

这样的模型耦合度太高，还是EOS的老样子，建议从“数据、行为、样式”的基础划分开来 最清晰

 

我不是很清楚“velocity不支持多次代码生成”是什么意思？用代码生成器第一次基于数据库元模型生成代码的时候，我们一般指定生成到项目开发路径（IDE）中，这不会对之前已经生成的别的实体的代码产生任何影响，如果针对已生成过代码的数据库表需要再次生成的话，可以在代码生成器中指定别的“项目路径”把新的代码指定到别的地方，然后再进行人工合并。

当然，利用平台进行开发的人员需要清楚生成的代码格式，因为针对特殊的业务逻辑是需要在此基础上进行修改的，我们不会像EOS那样去试图隔离程序员和代码，毕竟来说，代码还是最灵活的。

针对楼上的改版建议，我个人很感谢，但对于我们这种规模的团队来说，花大力气去将其做的大而全并不是我们的目标，花几个月做出这套东西对我们来说已经达到目的了，够用就行！写这篇文章的目的也是想将平台开发的一些经验和大家分享

最后说一点：我们的平台和东方易维的很类似，他们有的我们都有，如果大家对东方易维的产品有了解的话，可以做个比较

pconline900 的合并这部分没有必要搞的这么复杂,代码生成只是初始时生成一个基础结构文件,后续在此基础上增加业务逻辑代码,字段的增加可手工修改代码即可.

而我个人很厌恶的一点就是很多平台妄图将程序员与代码隔离,全部傻瓜式的,编写配置文件就可以实现某些功能,但这种做法又没有代码灵活.而且平台实现复杂.

而使用这种平台的更加郁闷,完全不了解平台,只知道使用这种工具.

 

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

别把EOS说得那么神秘 谁用过谁知道有多烂（当前的版本5.X）

codecreator现在成了每套框架必备的东西了

这个我赞成，不应该去试图隔离代码，应该给程序员更大的自由度

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

HibernateSynchronizer比lz的强大多了