普元EOS开发平台培训总结

普元[/b]EOS[/b]开发平台培训总结[/b]
[/b]

2004-02-22

（本文是某软件企业的技术负责人在接受普元EOS平台3.0版本的培训之后总结的心得体会。目前普元EOS产品的最新版本是5.0，作者提出的“5大缺点”如今是否仍然存在，尚且是一个值得思考的问题。）

一[/b] EOS[/b]开发平台的功能[/b]
[/b]

[/b]

普元EOS是一个快速开发平台。在这个平台的基础上，可以通过既有的一些构件的功能，来订制新的系统。

EOS专业版附带了权限和公共两个构件库，可选构件包括工作流，管理等部分。通过默认的构件库，能够轻松的调用并订制新的功能。

EOS提供一个Studio开发环境，订制过程完全图像化，可以用拖拉拽的方式实现。

对于一个全新的业务系统的开发，开发人员可以通过订制“表现自动机”，“业务自动机”等构建整个系统。系统会自动生成相应的代码并提交到服务器。

EOS提供一个称为数据字典的数据库映射工具，将数据库表映射成某个命名的实体对象。系统中调用命名的对象来访问数据库。

EOS提供一个JSP生成器，自动根据某个实体来生成相应的CRUD模版操作界面。

EOS支持多种应用服务器。支持部署在分布式系统上。

二[/b] EOS[/b]开发平台的优势[/b]
[/b]

[/b]

1 [/b]能够很快的开发出原形产品[/b]
[/b]

在了解了业务需求的情况下，几个熟悉EOS的开发人员可以很快地开发出产品原形。这适于对陌生领域的竞投标等采用。

2 [/b]学习曲线较[/b]J2EE[/b]低[/b]
[/b]

EOS的一些复杂技术对开发人员透明，开发人员不许要了解过多的EJB，应用服务器等使用，只要会操作EOS的各种工具，就可以开发和部署。只需要关注业务。

3 [/b]对客户的需求更改应变能力强[/b]
[/b]

整个开发都是基于图形化的流程界面，很少涉及程序代码，如果一旦客户的需求变更，只需要更新图形并重新生成代码。其他修改比较少。

4[/b]构件包可以不断积累[/b]
[/b]

EOS提供了一些基本包，大量的功能都已经封装好。同时，在不同领域的实施中，还会产生该领域特色的构件包，可以积累以供将来使用。

三[/b] EOS[/b]开发平台的缺点[/b]
[/b]

[/b]

1 EOS[/b]构件没有统一标准[/b]
[/b]

EOS的构件还没有一个统一的标准。这样就对后续开发和扩展产生了很大的影响。今后所有的产品都牢牢的绑定在EOS平台，移植性很差，完全失去了J2EE的灵活性。

2 EOS[/b]的一些概念定义含糊[/b]
[/b]

例如动态EJB，数据字典，构件等，并没有给出一个确定的定义。理解起来可能存在一定困难或偏差。而实际上，动态EJB和数据字典都是在炒作概念，并没有新意。

3 EOS[/b]会导致公司技术积累下降[/b]
[/b]

EOS的高度透明性同样带来了技术水平的降低。程序员无法掌握核心技术，这样一旦发生意外，很难靠自己解决。

4 EOS[/b]无法兼容旧有产品[/b]
[/b]

EOS的移植性很差，旧有的产品完全无法移植到EOS平台上。

5 EOS[/b]的工具还存在一定的差距[/b]
[/b]

它的工具易用性、成熟性等方面尚存在一定的差距。例如，各种工具尚未整合到同一个操作界面下等。

四[/b] [/b]对[/b]EOS[/b]的个人看法[/b]
[/b]

[/b]通过2天的培训，对EOS有了大致了解。可以认为，EOS是一个比较稳定的快速开发平台。然而，其中的一些概念或方法，都存在着较大的风险。

首先是整个EOS这个软件的思路，它定位于一种图形快速开发平台，通过对业务建模而生成最终代码。而国际上的标准是MDA（Model Driven Architecture）。MDA发展刚起步，它的核心是MOF或元数据，并且是OMG的标准。

反观EOS，它仅仅是通过订制流程图来定义业务，一没有一个全局的架构或概况设计，二没有对业务领域的建模。如果拿过去面向过程和面向对象来比较的话正合适，EOS就是面向过程的设计。然而，它的成品是面向对象的语言Java的代码，用面向过程的方式来写面向对象的Java代码，这就是它移植性差的原因。

其次，所谓构件。照我的理解，构件，就是能够反复使用的一套业务功能或模型，其重用范围应该是整套功能而不是某个类，例如订单系统，可能包含多个类，但复用是复用整个定单系统。Java中有portlet标准，即为门户定义的标准。每个portlet可对应一套构件。只要订单系统实现portlet标准，就可以在WEB上任意的地方重用订单。Java中被广泛接受的构件概念，是POJO或JavaBean，即带有业务功能的领域模型。

而EOS中的构件实际上就是一个类中的函数。根据我的分析，EOS实际上是将业务流程定义在XML文件中，然后用固定出入口的许多函数来调用和执行流程。按照它的这种方式，复用竟然具体到函数。每个函数都是用的类似的参数，一般是XML文档和实体对象等。

EOS并没有给出系统接口或扩展标准，后续开发或扩展很困难，开发一个复杂的系统风险很高。标准，关系到EOS的成败。

EOS不适合技术型的开发人员使用。大量雷同的操作和对核心技术的屏蔽会使热衷于技术的人失去兴趣。这平台对技术水平比较低，但对业务比较熟悉的技术支持人员可能会很有效。软件开发是人而不是机器的工作，因此，人的能动性在开发中起了非常重要的作用。忽视了对人的培养，只能带来更高的人员流动率。

EOS不能用于对现有OA产品的更新换代和移植。但可以用来进行新领域的竞标等方面。然而，不可忽视的是，由于EOS扩展的困难性和核心技术的缺乏，对EOS的依赖将不可避免。

以上是我对EOS3.0的总结。经过几天的培训，我认为EOS实际的平台比宣传的差很多，目前仍不能用于真正的企业级开发。