EOS/普元：中国IT业的悲哀

用过这样的框架，解决简单问题的时候的确很方便，但只要需求一复杂，立刻全员戒备，模块完成后整个team就像被轰炸过一样。

呜呼，再也不敢用了。

你的意思是“狂热的技术爱好者和钻研者”就一定会对EOS有所抱怨？或者你所接触的“狂热的技术爱好者和钻研者”都对EOS有所抱怨？如果是这样，那么一家视技术为生命的企业是否应该考虑这种现象为什么会出现，为什么自己的产品不能得到“狂热的技术爱好者和钻研者”的认可？而不是自以为是的以“业务才是最重要的”这样的话来自欺欺人。
另外，我本人还算不上你所说的“狂热”，看来抱怨EOS的人大有人在，至少这是值得深思的。


选择EOS是否“明智”，这个需要时间的检验，并非选择了就是正确，也不是普元有那个多案例，就意味着能得到那么多企业的认可。
“开源节流”这样的话是放之四海而皆准的道理，和你的论点没有任何关系。你在暗指选择EOS就意味着“开源节流”，但稍有逻辑判断的人都应该知道这两者间没有直接推理关系，要想证明就请具体详细论证。


业务是最重要的，但请问有脱离技术的业务吗？如果是这样，我们就不是软件公司，而是咨询公司了。似乎做平台推广的人都想让人知道一个道理：只要选择了我们的平台，你们就可以在技术方面一劳永逸了，因为只有业务才是最重要的。我感觉悲哀的是，偏偏有那么多人都赞同这个观点。
对了，EOS的价值是什么？请明确说明，也很希望你能就此深入论述，因为我也正在为EOS的价值而头疼，我很希望我们买的EOS能物有所值。


“语言”也不能解决所有问题，呵呵。
要说普元的“构件”，我上面已经表明了我的观点。这里再举个例子：在EOS中，连接两个字符串的操作是一个构件，向XML总线中放置一个常量也是构件，插入一条记录还是构件，面对这样的构件我真是无言以对，无法想象如果我们的建筑工人直接用沙子来建楼房会是怎样一种情形。


我非常赞成你上面的说法。但这些和EOS有必然的联系吗？这需要时间才能有答案。


我还是认为把EOS做为“平台”是其最大的定位错误，EOS有很多优秀的地方，但以我目前对EOS的了解，我认为EOS不适合做平台，原因在上面已经粗略禅述了。
你这里提到了spring/seam，不过我认为EOS和他们不具有可比性，虽然目前他们在企业中的定位类似。


我宁愿看到我们广大的程序员群体或者我们的IT技术人员具有较高的IT素质，而不是只有那么几家“优秀”的企业在独自和国外的厂商PK，因为基础不牢固，是建不起大厦的。


那篇贴子看过了，被说得一无是处的好象不是SOA吧？我觉得可以这样说：对SOA的理念不认同的人不多，现在的问题是SOA能否落到实处？很多厂家把SOA描绘得那么好，就是想让客户也明白，他们的SOA产品也能做到那么好，但理想与现实是有差距的，而且这个差距在我看来还不小，一如普元的“构件”。

jxb8901点评得比较犀利！

现在这年头，忽悠的人还少吗？不忽悠怎么能从客户那里拿到银子？
你不信、他不信，人家照样不急，因为有人信。
人家说的也不完全错，谎言往往只在某些细微的地方与真理有那么一点点的区别。
而且吧，人家说多了，自己都成信仰了，从人家的角度看，就是真理了。
所以，以谨慎的态度对待这些所谓的银弹，是每个开发架构师的职责！

应该自己搞个半编译，半解释型的语言，将核心功能以语句或内部函数的形式固化

从lz的贴子上看，现在的提供语言是无法同jruby<=> java这样的关系等同的,充其量只能算个模板语言

这样的框架如果动不动要动用底层的语言，像这里是java来解决问题的话，本身就是失败的

好帖，终于对普元的EOS有了个了解，谢谢。

别的不知道, 就知道EOS跟SOA一点关系都没有，却整天扛着SOA的大旗，确实比较搞。

jxb8901讲的很多设计上的问题, 确实存在, 我也使用过一段时间的EOS, 讲一些实实在在的问题:
性能很成问题, 机子要好点才行, 有同事甚至直接在服务器上修改页面, 因为项目大了后, 本机测试太慢, 受不了, 而只有服务器的高配置才行.
只有过程重用, 丧失面象对象的所有特性, 一个图形不能继承于另一个图形, 或覆写某个图形节点.
图形节点的粒度太细, 一个功能通常需要很多节点来完成, 最后都是蜘蛛网, 无法维护.
图形节点稍多，并且有节点环时，格式化图形(蜘蛛网), IDE就挂了．
对基本类型数据处理非常不方便, 如: 加法, 先用一图形节点设置原始值，再用一个图形节点向原始值累加，并存回原始值，感觉在用汇编的累加寄存器.
对复杂查询SQL的组装不灵活, 需要n多图形节点拼一个SQL.
生成向导过程不可保存, 在向导中某个地方写错了(并已点击完成), 必需重来.
所有"构件"内容未做索引, 查找功能基本是鸡肋, 查找需要非常长的时间.
重命名构件时, 默认选中自动修改引用, 但查找非常慢(整个项目遍历), 近半个小时才能完成, 也不进行提示, 通常只能杀死EOS进程.
很多.....

当然, EOS也不是一无是处, 也有优点:
做单表CRUD很快, 有单表生成向导.
工作流处理还行, 支持非正规流程.
基于Eclipse的IDE比较稳定.
图形化节点可脱离上下文单步调试.
也很多......

javatar说得不错，看上去有比较深入的EOS使用经验。

上面提到的EOS使用问题中有一部分是能根据EOS的设计分析出来的，比如关于图形结点粒度问题、过程式开发的问题、无数据类型的问题等，这些我们能预测到。但关于实际项目中图形过多的格式化问题、构件重构问题、构件查找问题等等都是实践中得来的非常好的经验。谢谢分享！

关于好处：EOS确实有许多优点，如果没有大的优点，是不可能得到那么多人认同的。比如上面提到的图形流程的可视化调试功能、工作流、报表引擎、可视化的JSP设计、等等。但这些优点中，有一些比如工作流和报表引擎本不应该是平台的功能，但被强加到平台，因为有许多项目是不需要使用工作流和报表的，也有一些是基本EOS的优点，比如其图形化的调试，这样的优点只能说是让错误的东西更加错误罢了。

关于EOS的优点也欢迎大家多多发表意见！