|
精华帖 (0) :: 良好帖 (14) :: 新手帖 (0) :: 隐藏帖 (3)
|
|
|---|---|
| 作者 | 正文 |
|
发表时间：2008-08-26
magicdoom 写道 呵呵 那个工作流引擎的截图看起来好熟悉
X.Y.D |
| 返回顶楼 | |
|
发表时间：2008-08-26
longlongriver 写道 楼上的很有科诺ＫＡ-2平台的感觉，不同的是你的是以数据库驱动的，而且生成器是基于ｅｃｉｌｉｐｓｅ的插件来设计的。
我以前也用过ＫＡ－２，我的东东在权限这块除了ｊｇｕａｒｄ外，也借鉴了很多它的权限设计的思想。 另外问一下，不知道楼上是怎么解决你的流程性应用这块的需求？ 向导连接数据库生成是主要的方式，另外也提供了自己用上面的模型编辑器重新创建一个数据模型的功能，然后根据这个模型生成代码，这种方式可以不用连接数据库。 流程性应用方面使用的Jboss Jbpm |
| 返回顶楼 | |
|
发表时间：2008-08-26
badqiu 写道
longlongriver 写道
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工程，会自动编译，所以支持 以上不是一个简单模板可以实现
我不是很清楚“velocity不支持多次代码生成”是什么意思？用代码生成器第一次基于数据库元模型生成代码的时候，我们一般指定生成到项目开发路径（IDE）中，这不会对之前已经生成的别的实体的代码产生任何影响，如果针对已生成过代码的数据库表需要再次生成的话，可以在代码生成器中指定别的“项目路径”把新的代码指定到别的地方，然后再进行人工合并。 当然，利用平台进行开发的人员需要清楚生成的代码格式，因为针对特殊的业务逻辑是需要在此基础上进行修改的，我们不会像EOS那样去试图隔离程序员和代码，毕竟来说，代码还是最灵活的。 针对楼上的改版建议，我个人很感谢，但对于我们这种规模的团队来说，花大力气去将其做的大而全并不是我们的目标，花几个月做出这套东西对我们来说已经达到目的了，够用就行！写这篇文章的目的也是想将平台开发的一些经验和大家分享 最后说一点：我们的平台和东方易维的很类似，他们有的我们都有，如果大家对东方易维的产品有了解的话，可以做个比较
而我个人很厌恶的一点就是很多平台妄图将程序员与代码隔离,全部傻瓜式的,编写配置文件就可以实现某些功能,但这种做法又没有代码灵活.而且平台实现复杂. 而使用这种平台的更加郁闷,完全不了解平台,只知道使用这种工具.
|
| 返回顶楼 | |
|
发表时间：2008-08-26
seemoon 写道 很不错了，有点ror的味道了。另外有没有考虑一些convention的问题？这比较细节化了，也就是说，生成的代码到实际可用有多少距离，又比如界面要完全另做，如何实现？
界面完全定做很容易的，根据新的UI重新定义一套模板文件就OK了，只要你的元数据模型保持稳定就没有问题 |
| 返回顶楼 | |
|
发表时间：2008-08-26
cdxuyi 写道 eos 承载的是软件工程的思想 ，studio及工作流 ，无出其右
国内工作流引擎做的最好的应该是西安协同和杭州信雅达。ｅｏｓ可能还排不上前十吧！就我知道的，上海比ＥＯＳ的流程做的好的就有好几家，比如东兰... 工作流这东西应该是Ｊ２ＥＥ体系中最核心的东西了，ＥＡＩ、ＥＳＢ、ＢＰＭ无比牵涉到它，我之前这块的选型花了不少功夫，原来计划是用开源的ｊｂｐｍ，但它的ｓｔｕｄｉｏ及ＦｏｒｍＤｅｓｉｇｎｅｒ都不满意，最后还是推翻了，重新用了商用产品，呵呵！ |
| 返回顶楼 | |
|
发表时间：2008-08-26
pconline900 写道 seemoon 写道 很不错了，有点ror的味道了。另外有没有考虑一些convention的问题？这比较细节化了，也就是说，生成的代码到实际可用有多少距离，又比如界面要完全另做，如何实现？
界面完全定做很容易的，根据新的UI重新定义一套模板文件就OK了，只要你的元数据模型保持稳定就没有问题 想问一下页面文件和配置文件用的是什么代码生成引擎呢，不能也是jet吧 |
| 返回顶楼 | |
|
发表时间：2008-08-26
西安协同 呵呵 我见识过了 专门做工作流 这块比eos 的工作流 不在一个级别
估计楼上说eos 的 基本没用过 eos工作流 说单个代码看 eos 不算什么 一个软件产品 不就是承载了开发思想嘛 至于代码 单个看没意义 ，至于 eos中的基于web的流程定制平台 ，没见识过其它的了 |
| 返回顶楼 | |
|
发表时间：2008-08-26
seemoon 写道 很不错了，有点ror的味道了。另外有没有考虑一些convention的问题？这比较细节化了，也就是说，生成的代码到实际可用有多少距离，又比如界面要完全另做，如何实现？
初始代码是依据模板生成的，目前我们用的模板都是调测过的，如果不加自己的特殊业务代码的话，直接编译后就可以跑了，所有的配置文件都是自动生成的，只需要将生成的spring和struts的配置文件手工注册到web.xml和总applicationContext.xml文件中就可以了 另外，我们的代码生成器并不和IDE帮定（流程性应用设计除外），实际上生成代码后，就和它再没有关系了，你想怎么改就怎么改，界面完全另做你既可以直接改页面文件，因为后台的DAO和Server、Action都是通用的（这些代码你也可以自己改），也可以根据别的模板来再次生成，还是那句话，想改哪就改哪！ 不过用平台开发之前还是需要一个培训的过程的，这也是必须的，我们对内有个80页左右的文档，一般一个普通程序员（知道struts、spring、hibernate）3天左右的时间可以熟悉整套平台构架并熟练开发，但如果想做到熟练使用流程设计器来做流程性应用的话，可能需要更长的时间，毕竟工作流的一些设计模型比较抽象，要说清楚的话，我估计又要单开个专题了，呵呵。。。 |
| 返回顶楼 | |
|
发表时间：2008-08-26
lszwycn 写道 pconline900 写道 seemoon 写道 很不错了，有点ror的味道了。另外有没有考虑一些convention的问题？这比较细节化了，也就是说，生成的代码到实际可用有多少距离，又比如界面要完全另做，如何实现？
界面完全定做很容易的，根据新的UI重新定义一套模板文件就OK了，只要你的元数据模型保持稳定就没有问题 想问一下页面文件和配置文件用的是什么代码生成引擎呢，不能也是jet吧 模板引擎可以产生任何文本文件，properties xml jsp php aspx c# sql.......都没有问题 |
| 返回顶楼 | |
|
发表时间：2008-08-26
采用JET引擎是基于Eclipse平台开发的通用做法。
楼主的代码生成器作为平台级的东西是没有什么亮点，只做工具不做平台太可惜了 所谓将“程序员与代码隔离，全部傻瓜式的,编写配置文件就可以实现某些功能” 代码隔离不是剥夺写代码的权利，这也是将工具做到极致后，形成一套完整的编程模型的做法。即便你们现在的工具还没做到这样，但方向也是如此！ |
| 返回顶楼 | |
