也谈普元

偶然间看到下面有一个网友慨叹普元的强大，而开发人员的渺小。
小弟刚刚参加工作，也在项目中接触到了普元的EOS。普元的这个东西怎么说呢，就是乱用XML然后Spring没做好就变成那个样子的，同时失去了类型的表述，一部机器要进行装配需要组件和零件，软件应该自上而下，分而治之，这是上个世纪70年代，学者们就达成的共识，所以关于“银弹”神话的唯一结论就是——“没有银弹”。
为什么说EOS是没有做好的Spring？
Spring简化了对象的装配，强调重用，是建立在面向对象基础上的，是建立在敏捷测试基础上的，是建立在强类型基础上的；
而EOS则是建立在面向过程的基础上的，建立在不可测试的基础上的，建立在毫无类型基础上的（全是String）
然而EOS也有很多的优点（据小弟不完全发现）：
1）EOS固化的开发流程强制一个team从一种易于维护的结构组织Web，包括页面，表示层，逻辑层等等。否则的话就需要一个架构师来做出规约，但仍不易于管理；
2）EOS的画图功能让人耳目一新，从“代码即文档”的哲学出发，这些画图很好地诠释了代码表述的内容和结构，给程序的维护带来便利。
3）相对于OO和J2EE传统开发，EOS易于上手，学习曲线较短。但是这一点有争议，EOS的知识不具备通用性。
综上，根据2-8的关系法则，在某些领域EOS的确有其优点，但是认为EOS完全“解放”了程序员，则是不负责任的说法。
这只是我的个人看法，欢迎大家就此话题讨论。

EOS把业务人员和programmer解藕合了,有点点这个意义

第一点：一个成熟的团队都应该有符合实际的最佳实践，比如你用了spring，他有他的约束和实践，但你要在此基础上根据实际情况在做一些抽象、简化和封装，做一些约束和规范。如果你这些都不愿意做，那可以用EOS之类的产品了，虽然不一定适合，不过对于那些根本没有抽象和管理能力的团队还是有点用的。

 

第二点：图如果能作为文档，又能作为可执行代码的一部分，那确实很好。不过不是所有的问题都适合用图来解决，你用一个图来弄个最简单的冒泡排序试试，肯定没有代码的表达能力强。图适合整体的规划而不善长算法和细节。所以EOS中业务层也试图用图来解决，我觉得不太合适。可以试试spring web flow或seam的page flow解决页面流的问题，使用JBPM之类的工具解决工作流的方面，他们都很容易图形化的。

 

第三点：我不觉得EOS容易上手，只是可以它的IDE帮你生成了一些简单的东西。稍微一点的问题就不好解决，需要深入学习他的那一套东西。EOS的知识不具备通用性也是不容易学习的一个原因。

 

如果EOS适合20%的应用场景那还算是他做的不错，怕的是他在一个应用中只能简化20%的开发，而复杂化80%的部分。

 

我的建议是，把买这些工具的钱省下来去请一个有经验有水平的真正的程序员，在实践中培养一个稳定卓越的团队，抽象出一个符号自己实践情况的规范和框架（或对其他的框架进行精简和封装）。

微软ERP也出中文版了，最近看了展示，连XML都不用写，选几下就能用，估计以后又要热闹了。

公司的项目开始渐渐使用EOS 来开发了电信集团的项目了，通过和使用EOS的同事的交流，就事论事的提出以下EOS的缺陷：
1.首先EOS不开放：里边集成的JBOSS都是很老的版本，不支持外部配置application server.
2.EOS不是面向对象的： 程序员的开发过程是依据流程式的面向过程的。连最基本的可重用性都不具备。
3.EOS很难维护： 如果数据库有小的变更，就牵扯到修改所有的参数。
4.EOS存在out of memory.问题，和其他bug.

普元的EOS基本上就是让键盘下岗了

还有.技术人员不懂技术了(画图拖拽),业务人员要多了解技术了(看怎么把业务用EOS实现,不能实现的需求尽量避免)

普元做SOA大会等一些会议 实际上是在提升他们公司的知名度和影响力，就像可口可乐 蒙牛做广告一样
在其广告效用生效之后，接下来就是业务员去忽悠一些公司的Ceo，ceo不懂技术但是知道这玩意有名堂 就买啦
这是知名公司惯用的伎俩， 其目的就是使其产生商业价值或者让其成为行业的领军人
倒霉的是这一系列的动作都会波及到我们程序员，有时候我们就会被这些大公司牵着鼻子走，他们说啥技术好我们就学啥技术，而这些技术很多都是没有用的 白白浪费了我们的时间
所以我们一定要擦亮自己的眼睛，仔细分辨那些是有用的 那些是没有的

个人觉得

如果软件是来规范业务的，EOS还是不错地
如果软件是来被使用者或者决策者肆虐的，EOS没有价值

不谈技术,忽悠到越来越多的人关注普元并试用其产品.说明普元已经成功了,普元之前一直做的就是国内软件企业一直欠缺的市场营销.