EOS5.0到EOS6.0.doc

据说EOS6将最近正式发布。虽然之前也听说过EOS6将有一些重大变化，但毕竟听到的只是只言片语，加上官方网站上对EOS6的介绍也是少之又少，所以一直想象不到EOS6的变化究竟有多“大”。 今天拿到了EOS6的文档及安装程序，花了一个下午的时间安装、阅读开发手册、试用，感觉仍是不得要领。XML总线没有了、页面逻辑没有了、业务逻辑没有了。页面流、逻辑流、服务、接口、构件装配、引用等等新概念让人无所适从。虽然还是有熟悉的EOS开发视图、EOS调试视图，但很明显：EOS6已远非我们所熟悉的那个EOS5了。嘿嘿，一句话：从EOS5到EOS6，那变化是相当的大。 又花了一个晚上的时间翻看了EOS studio附带的开发文档和参考手册，终于对EOS6的变化和发展有所理解和领悟，特地记录下来，希望能帮助后来者减少学习的成本。 从EOS5到EOS6的变化，可以类比为从Basic到Java的变化。从Basic到Java，就是从面向过程到面向对象，这是Basic和Java最大的也是最本质的差异，同样这也是EOS5和EOS6最大的也是最本质的差异。 1、 在EOS5中，业务逻辑甚至是页面逻辑都可以认为是Basic中的一个函数或过程，而在EOS6中业务逻辑被“构件”和“逻辑流”两个概念代替了，EOS6中的一个“构件”可以有多个“逻辑流”。为什么要把EOS5中的一个概念拆分为EOS6中的两个概念呢？因为EOS6面向对象了。在EOS6中，一个“构件”可以被认为是一个Java类，而“构件”中的“逻辑流”就相当于Java类中的一个方法。甚至于为了更加的面向对象化，EOS6中的参数都可以是任意的Java对象，而在之前的EOS5中，这是不可能的，因为XML总线中只能存在有字符串。 2、 在EOS5中，运算逻辑只能是静态方法，而且所有运算逻辑的方法签名都是固定一致的，必须接受一个XML总线作为参数，因此我们也可以在认为EOS5中没有过程或函数的形参和实参的封装，而只有全局变量。但在EOS6中，这一切统统被改变了，因为EOS6需要面向对象化。在EOS6中，运算逻辑可以是任何Java类的任何方法，甚至是非静态方法！对于习惯了过程式编程的程序员来讲，这一点可能是不可接受的，他们认为静态方法已够好的，他们无法理解为什么需要非静态方法（实例方法）。事实上EOS6这样做了，我想EOS6的设计者们有他的理由和想法。 3、 EOS5太简单了，从语言层面来看，没有太多可说的东西。但EOS6就不一样了，为了实现面向对象化，EOS6甚至引入了面向对象语言的核心概念：接口。虽然有人不同意，但以现今的程序开发眼光来看，“接口”这一概念的重要性要比面向对象中的“继承”概念的重要性大得多。EOS6恰恰实现了面向对象的“接口”概念而没有实现“继承”，我认为这一点不会影响EOS6进入面向对象语言殿堂的可能性。 4、 EOS6不仅仅是Java1.3或Java1.4，EOS6是Java5。因为EOS6实现了Java5中的变长参数，另外EOS6的运算逻辑全部支持Java5的Annotation（注解），EOS6的Java API也都支持范型，EOS6的IDE和服务器都运行于JDK 5。 5、 EOS6中的构件支持依赖注入（DI），EOS6 Server相当于一个IOC容器。近年非常火爆而今年风头稍减的名词IOC，所表达的设计理念也被EOS6所采用了。只是换了一个说法，一个近年风头更劲的名词SOA。要说EOS5支持SOA，了解的人都是相视一笑，大家都不说穿罢了。而EOS6那才是货真价实的SOA架构，据说EOS6实现了SCA/SDO规范。SCA中的构件装配就类似于IOC容器中的组件装配，构件只需声明依赖，其依赖关系可以由容器自动解决，类似于IOC中的依赖注入。事实上通过部分EOS6的代码可以看到，EOS6中使用了Spring2，可以想象EOS6的IOC应该有Spring的影子。 6、 EOS5简单，EOS6复杂。EOS5之所以简单，是因为其提供的功能弱，概念少，就如同Basic的简单是一样的道理。但EOS6就不同了，仅是新概念就增加了不少，如：接口、引用、实现、服务、构件、逻辑流等等；另外EOS6还引入了SCA/SDO的概念，什么DataObject，DataGraph，MUO等等。这些无疑会增加EOS6的入门难度和学习难度。 7、 EOS5中的XML总线被EOS6中的数据上下文的概念所取代。曾经，XML总线可是EOS引以为豪的骄傲。如今，新的SOA/SCA/SDO风头正劲，XML总线自然也要完成其历史使命退隐江湖了。其实EOS5的XML总线理念相当简单，就是一个树状结构的字符串类型的全局变量池。但为了支持面向对象，EOS6也只能忍痛割爱另寻新欢了。EOS6中的数据上下文其实和XML总线类似，但支持任意的Java类型。事实上就相当于一个基于线程局部存储的变量池，或者简单来说就是一个Map。但就是这样一个从字符串类型到任意类型的看似简单的改变，将深刻影响EOS6开发的各个方面。 8、据EOS的文档讲，EOS6支持AOP，虽然我还未了解到EOS6是如何实现的AOP，又实现到了什么程度，但我想面向对象的EOS6实现AOP应该不难。 8、EOS6与EOS5完全不兼容。虽然没有看到EOS关于升级和迁移的文档，但通过对比分析我们可以得出如下结论：原有的基于EOS5的业务逻辑是无法迁移到EOS6中的，也就是说所有的业务逻辑必须重新开发，这对于基于EOS5做了大量应用的公司来讲不是一个好消息。 至此，我们似乎隐约看到了EOS的发展肪络。曾经，EOS5被我们许多人所赞叹甚至为之而自豪，而今天，EOS6对EOS5的一些东西的抛弃，是否应该引起他们的思考呢？从面向过程到面向对象，从简单到灵活，从容易到复杂，这好象也是当今软件的发展之道。看到EOS这样的变化，也许我们应该欣喜，毕竟他在进步。 从EOS5.3到EOS6似乎用了近三年的时间，也就是说EOS花了三年时间实现了其本质上的变迁。但中国整体的IT水平能跟上这样的变迁吗？如果不能，那么我们可以预言，EOS6在推广上将远不及EOS5。 注：因为这篇文章仅仅是在接触了EOS6几个小时后所写，文章中对EOS6的理解难免会有错误，欢迎大家补充、讨论、批评和指正！ 为了避免大家误会，我这里再补充说明一下我个人对EOS6的看法： 看到某些人说EOS6多么多么的好，我其实是不以为然的，EOS6固然有它的亮点，但我敢说：EOS6对于那些对“图形化”开发不感兴趣的程序员来讲，EOS6仍然不具有吸引力，而对于那些视“代码即设计”的程序员来讲，EOS6又简直就是鸡肋。本质上来讲，EOS6就是java加上了sprin