一.普元公司对EOS的描述
1.EOS开发平台的功能
普元EOS是一个快速开发平台。在这个平台的基础上，可以通过既有的一些构件的功能，来订制新的系统
EOS专业版附带了权限和公共两个构件库，可选构件包括工作流，管理等部分。通过默认的构件库，能够轻松的调用并订制新的功能。
EOS提供一个 Studio开发环境，订制过程完全图像化，可以用拖拉拽的方式实现。
对于一个全新的业务系统的开发，开发人员可以通过订制“表现自动机”，“业务自动机”等构建整个系统。系统会自动生成相应的代码并提交到服务器。
EOS提供一个称为数据字典的数据库映射工具，将数据库表映射成某个命名的实体对象。系统中调用命名的对象来访问数据库。
EOS提供一个JSP生成器，自动根据某个实体来生成相应的CRUD模版操作界面。
EOS支持多种应用服务器。支持部署在分布式系统上。
2.EOS开发平台的优势
1 能够很快的开发出原形产品
在了解了业务需求的情况下，几个熟悉EOS的开发人员可以很快地开发出产品原形。这适于对陌生领域的竞投标等采用。
2 学习曲线较J2EE低
EOS的一些复杂技术对开发人员透明，开发人员不许要了解过多的EJB，应用服务器等使用，只要会操作EOS的各种工具，就可以开发和部署。只需要关注业务。
3 对客户的需求更改应变能力强
整个开发都是基于图形化的流程界面，很少涉及程序代码，如果一旦客户的需求变更，只需要更新图形并重新生成代码。其他修改比较少。
4 构件包可以不断积累
EOS提供了一些基本包，大量的功能都已经封装好。同时，在不同领域的实施中，还会产生该领域特色的构件包，可以积累以供将来使用。
二 普元构件的本质
1.面向构件开发，提高软件质量和复用
普元的面向构件就是指：定义一个结构（可以认为是一个函数一样的东西）。在结构中，定义输入和输出，就形成了一个构件。每一个Http访问，会建立一个线程
级（ThreadLocal）的变量，里面存放一棵xml树。在这个线程的运行过程中，会不停的增加，修改，查询定位树中的节点。这个过程使用xpath
实现。据说xpath部分是他们自己重写过的，为了提高效率。
答：普元EOS实际上是面向流程而不是面向对象的。因为构件，可以理解为一个过程或函数。这种模式是不是真正面向构件的，估计没有多少人认同吧。
我们常说的构件技术只有三种EJB、CORBA、DCOM，之所以认为这三种为构件技术，主要是因为有以下共性：
提供了对象生命周期管理：我们可以不用对对象的创建、销毁、安全进行管理，由容器统一管理
提供了分布性功能：由容器对访问的对象位置进行管理，开发人员不必考虑
提供了跨平台功能：不同类型的语言都可以对其进行访问
构件的复用级别依然是对象级的。
2.普元公司提供了大量的公用构件、ABFrame（组织权限管理框架）以及使用拖拽图元来定义其页面流、逻辑流等。
答：公用构件其实就是我们所封装的很多公用方法，如对数据库底层的操作的公用方法、对web service所封装的公用方法。只要是做技术的人，谁不对此进行封装。
3.通过向导或者图元的拖拽就可以生成一个功能模块，提高开发效率
答：EOS其实就是一个图形化开发平台，通过拖拽操作自动生成一些辅助代码。可是，这种辅助生成代码
只能生成一些简单的功能，类似于代码自动生成工具
三 EOS开发平台的缺点
1 EOS构件没有统一标准
EOS的构件还没有一个统一的标准。这样就对后续开发和扩展产生了很大的影响。今后所有的产品都牢牢的绑定在EOS平台，移植性很差，完全失去了J2EE 的灵活性。
2 EOS的一些概念定义含糊
例如动态EJB，数据字典，构件等，并没有给出一个确定的定义。理解起来可能存在一定困难或偏差。而实际上，动态EJB和数据字典都是在炒作概念，并没有新意。
3 EOS会导致公司技术积累下降
EOS的高度透明性同样带来了技术水平的降低。程序员无法掌握核心技术，这样一旦发生意外，很难靠自己解决。
4 EOS无法兼容旧有产品
EOS的移植性很差，旧有的产品完全无法移植到EOS平台上。
5 EOS的工具还存在一定的差距
它的工具易用性、成熟性等方面尚存在一定的差距。例如，各种工具尚未整合到同一个操作界面下等。
四 结论
EOS仅仅是通过订制流程图来定义业务，一没有一个全局的架构或概况设计，二没有对业务领域的建模。EOS只能沦落为一个简单的代码自动生成工具。
EOS的技术水平比较低，理论与实践严重对不上，举着构件的大旗，做着自己都知道骗人的把戏，注定就是一个怀具。
其实普元真要把带图形化的代码自动生成工具做好也是挺不错的。
阅读(6452) | 评论(0) | 转发(0) |
