有人了解普元 primeton EOS 产品的么?可否评价一下?

我看了他的技术资料和DEMO,从生产率上来看,似乎很高。
而且对程序员要求降低很多。
性能方面,应该对于一般的应用也不是大问题。
而且性能调优有很多方面,只要EOS的应用架构上还合理,就应该不是问题。
价格就不用说了,嗬嗬,吓人。
坛子里面有没有比较熟悉它的?可否从比较深入的角度来评价一下它?

我目前觉得他的XML数据总线是个好东西。
可是,不停地把数据或者对象向BUS里面序列化和反序列化,难道就不会出现性能问题么?

不太清楚其产品,现在国内有很多所谓可视化智能UI产品,这是走上了与领域驱动设计相反的道路,表面上开发速度提高,Eric Evans认为智能UI其实是反模式的。从域驱动角度看:真理应该是领域和UI分离。

假如你是名资深的架构师,且你使用了其产品,熟悉该EOS平台后,你将立马感觉到自己被骗了,原因很简单,该平台的快速开发到底快在哪?它是快在了自己做了非常多了公用构件、ABFrame(组织权限管理框架)以及使用拖拽图元来定义其页面流、逻辑流等,而这些如果你做为一名资深架构师,你将立马清楚其中的道理是公用构件其实就是我们所封装的很多公用方法,如对数据库底层的操作的公用方法、对web service所封装的公用方法等等,这些公用方法难道你做为一名资深架构师,你不会去封装吗?如果你会去封装,那你又何必去使用该平台的构件呢?你完全可以使用自己所定义的公用方法,那么关于构件可以为你提高开发速度就立马可以被排除;其二、关于组织权限管理框架,用户组织权限管理一般的管理类信息系统都需要,你做为一名资深的架构师,难道没有对这块的功能做单独的设计吗?如果有,那么该模块的功能你又基本上可以在多数的管理类信息系统去复用自己所设计的这块用户组织权限管理(当然,权限管理的需求可能不尽相同,但你也完全可以在自己所设计的基础上而改进啊,这样的改进也是容易的,ABFrame也同样绝对性的满足你的需求,你同样也需要改进),那你又何必去用它的这个框架呢?因此ABFrame所带来的提高开发效率问题再一次的被排除在外;其三、图元的拖拽以及开发向导等,这些我想也是忽悠人,因为这对于一个公司的高层来说,开着通过向导或者图元的拖拽就可以生成一个功能模块,致使他们非常激动人心,可事实是什么?事实一:这些所有的拖拽后功能的实现都是基于公用构件的封装;事实二:拖拽或者向导在实际系统开发中并不是无需更改或者无需设置参数。根据这两个事实,那么如果你做为一名资深的系统架构师你都已经实现了自己的公用封装以及自己的公用组织权限管理框架,你又何须用该平台呢?
结论:这样的东西在没有资深技术基础的政府机构、国有企业、事业单位非常容易忽悠。哎,悲哀!不知道是发明者的悲哀,社会的悲哀,还是谁的悲哀。
[该贴被tsrj于2009-03-19 09:46修改过]

我倒是听说他们产品卖的不错,而且我朋友的公司就在用,感觉还是褒大于贬的。
就Abframe来说,本来就是开源的东西,自己想怎么改就改好了,我个人也参与过改造Abframe,不是很麻烦。

谈到自己封装,只要是公司肯下狠力,统一一个环境进行封装,把项目经理的技术选型权彻底上收了,那就绝对没问题了。主要还是看公司看不肯自己花这个经历做这件事。尤其公司大了,产品条线多了,想搞这个“统一”太难啊。

他们的理念非常好。具体产品是否实现了该理念,我不大清楚

EOS是什么:
1、EOS是一个基础业务平台,
他提供了一个应用的运行环境--EOSMGR,所有的EOS应用必须在EOSMGR的管理之下;
一个ORM的机制:类似于iBatis的一个ORM框架,可以由表、SQL语句生成数据实体;
定义了Request-Response的处理流程:JSP--展现逻辑--业务逻辑--数据实体的访问顺序;
对事务处理的封装;
一堆的标准构件--也就是我们常用的助手方法库;
一堆的自定义标签;
一推的自定义JS库,支持AJAX调用;
内部的数据传输全部是XML;
支持工作流开发;
支持定时任务、异步任务、单元测试;
提供基于Eclipse的集成开发环境;
2、使用EOS平台之后
架构师:主要职责就是处理EOS与其他系统、框架的兼容问题;
程序员:主要就是写JS,和拖拉构建;
3、优缺点:
优点:程序员上手快,起码比培养一个Java程序员的周期短很多;
部署比较方便;
缺点:效率低,频繁进行XML数据的转换,效率肯定低;
对事务的处理有欠缺,尤其是查询、更新与存储过程同时在一个事务中时;
不开发底层调用接口,如果你想和数据总线直接打交道,除了反编译,估计就没什么办法了;
在不同项目之间,根本没有复用的可能,修改构件的属性还不如重新拖一遍来的快;


个人看法