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

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

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

zan cheng louzhu

适合自己团队的才是最好的。

呵呵，不管EOS的受众目标定位是什么，就我所接触到的事实是，最终用EOS的还是开发人员，这和楼上所谈的好像有些差距！
至于自己开发维护一套平台，如果一切自己从头构建的话，肯定成本高，也不现实，但J2EE体系最大的优势就在于有众多的开源中间件可供选择，完全不用重复发明轮子。我的文里已经说的很清楚了，这个平台除了工作流引擎之外（这个我会另外起个贴详细说说），其它所有的组件都是用开源产品来组装的，至于代码生成器，则是基于netbeans的RCP用了2周不到的时间自己写的。平台定型后，我们目前并没有专门的人员去维护它，但基于各个项目的反馈，平台依然能够获得不断的完善，我并没有觉得维护成本有多高，倒是基于这个平台，我们能够为开发人员节省下大量的开发时间和精力，投入到业务或其它领域的研究中，而且开放的平台也提高了技术人员研究技术的兴趣，热衷于去扩展它的功能，弥补不足。另外，出乎我的意料的是，自从平台上线之后，团队的精神面貌和以前有了很大的不同，项目也做的更加从容，大家都能进步，完全是一种良性循环的局面。

对，适合于公司的技术架构的工具就是最好的，何况这个工具开发工作量很小，偶前面发的这个工具也就是两个人一个月从概念到产品出来搞定的，还包括学习Eclipse插件、EMF、JET等技术的时间，最后统计代码量也就一万多行

EOS的失误就是太重量级了，什么都想涵盖，太理想化想解决所有的问题；自己做的代码生成工具是适合企业特点的，很轻量级别的工具，定位为开发辅助工具，所带来的效果是非常不错的。就类似于EJB和Spring的区别了

eos 是典型中国人的软件。

犯的也是典型中国人的臭毛病。

矫枉过正。

但还跟着ibm，bea，非要和soa 拉上关系，跟着洋人屁股后面混。

最后也就落个吃洋人屁的下场。

我不信 现在的编码人员 不想跟着洋人屁股后面混 struts spring hibernate seam jbpm  那个是国人自己写的
相反 我挺佩服 普元的开创性 和坚持， 能跻身参与soa 标准，对中国本土软件企业本身是很难的事情。

长见识了。我现在也在开发一套通过xml配置与java注解生成增，删，改，列表组件。