05年的时候,普元来我们产品线推广EOS5.0,正赶上我们部门也在开发自己的框架,于是大家就PK了一把(普元的上层推销能力不是一般的强,不是盖的,已经搞定了几乎所有的老大,合同都签了)。
当时我们就把自己的框架和EOS比较了一下,想起来,就和楼主说的E0S5和6的比较一样,普元没人论的过,我记得普元的程总也亲自来了,还有好几个在javaeye上的活跃同志也来了,名字我就不说了。
我们05年的框架,也是基于Spring的,也是数据上下文的概念(不过不是eos6的那种简单的map形式),也是基于SCA/SDO来考虑服务和数据,通过OSGI来进行模块的物理和逻辑的解耦合。
想想当年PK的时候:
面向对象的数据上下文 PK EOS的XML数据总线(golobal xml document)
基于Spring的SCA服务装配 PK 普元的静态方法调用
基于SDO的数据模型 PK EOS的XMLDOCUMENT
采用OSGI的模块独立技术 PK EOS的部署技术
等等等等,整个过程持续了多长的时间啊,最后还是我们的框架胜出了,如今基于我们框架开发产品已经在全国各地应用了。
时移世易,终于看到普元走上了正路,我也为他们高兴,:D,只是,普元兄弟,你上路太晚了,这都是05年的东西啊。
当时我们就把自己的框架和EOS比较了一下,想起来,就和楼主说的E0S5和6的比较一样,普元没人论的过,我记得普元的程总也亲自来了,还有好几个在javaeye上的活跃同志也来了,名字我就不说了。
我们05年的框架,也是基于Spring的,也是数据上下文的概念(不过不是eos6的那种简单的map形式),也是基于SCA/SDO来考虑服务和数据,通过OSGI来进行模块的物理和逻辑的解耦合。
想想当年PK的时候:
面向对象的数据上下文 PK EOS的XML数据总线(golobal xml document)
基于Spring的SCA服务装配 PK 普元的静态方法调用
基于SDO的数据模型 PK EOS的XMLDOCUMENT
采用OSGI的模块独立技术 PK EOS的部署技术
等等等等,整个过程持续了多长的时间啊,最后还是我们的框架胜出了,如今基于我们框架开发产品已经在全国各地应用了。
时移世易,终于看到普元走上了正路,我也为他们高兴,:D,只是,普元兄弟,你上路太晚了,这都是05年的东西啊。