闲扯普元EOS

前几天，小错那篇EOS的文章招来了两位为普元说话的人，我很赞同小错后来这篇POST里的观点。先不说普元EOS在技术上的优劣，就拿他们最近在《程序员》的宣传来说，基本上都是属于高来高去的扯淡性质的东西，无非是反复在说EOS很好很好。但这是远远不够的，必须要能拿出清晰明了的技术说明才能让人信服并接受，比如像小错那篇《初窥EOS》这样的文章，把具体的技术细节拿出来接受检验——除非它在技术上的确有不便让人知道的不足之处。

再说来技术。普元的EOS其目标是想要实现“构件”级的可复用，正如恶魔在第六期的《程序员》中有一篇文章《质疑：从面向构件看软件复用》所指出的那样：所谓构件的粒度过大，注定不会有好的可复用性，并且他拿轻量容器PICO作比较说明，很有说服力。

而普元解决这个问题的办法似乎是通过用XML来作为构件间的接口，通过“弱”约束来改善大粒度构件的复用问题。当然，我相信普元的构件也是可以做小的，但是看上去构件似乎是一种重量对象，如果做成小粒度的，必然导致接口成本的大幅上升。这个矛盾目前看来是不可调和的。

回到XML的问题上来。我不想再说XML的性能问题，毕竟在复杂应用中，只要不滥用，这点性能损失通常还是可以接受的。我要谈的是“弱”约束的问题。

从目前已知的各方面来看，在EOS中XML似乎是被用作非强类型的数据接口定义，这就变得如令狐在他那个WebService实现中那样的做法了：客户端与服务端之间的调用约定是“弱”约束，双方必须自觉遵守，否则将在运行时出错。这也是小错指出的EOS的第三点别扭之处。

其实在令狐那个WebService中是可以用强类型数据的。只是麻烦：首先要为这些类型增加Serialize接口，然后在Web Service端要以wsdd形式配置并发布，客户端也要做一些处理……这一方面与DELPHI很类似，都是需要自己实现对非基本数据类型的序列化，然后注册，就可以在导出的WSDL中提供相应的约束（参见我的一篇关于用Delphi进行WebService开发的文章，其中用的还是默认的序列化方式，自定义序列化可以通过NativeToXS 和 XSToNative两个方法实现）。

但 在普元EOS中，我没有看到这个方面。所以我认为，从这个角度上说，EOS甚至不如目前流行的SOA的概念。SOA作为一项基于WebService的技 术，可以充分利用WebService提供的这一套标准的处理机制，并且它是以整合既有系统为目标设计的。就算普元EOS的开发成本很低，对于存在既有应 用系统的情况，重新开发的成本总是会比整合既有系统要高的。当然，如果没有历史包袱的话，EOS也还是有优势的。

我 之所以比较不喜欢这种“弱”约束，原因就在于前面所说的一点：它只会在运行时出错。而对应的强约束则可以在编译时得到检查。它等于在一个方面减少工作量的 同时，在另一个方面增加了工作量——把本来应该由编辑器处理的问题交给程序员来做。至少需要增加不少本来不必要的单元测试工作。

不过这倒让我想到，如果是动态语言的话，可能会在粒度和接口复杂度之间取得比较好的平衡。

BTW：看到小错那篇后面又多了不少回复。牛者恒牛说：EOS降低了J2EE的门槛，提高了开发效率（大意）。这可能是事实，但是我不能同意这一句：我用你一半的时间完成你相同的工作，完成的系统更稳定更易维护。

稳定性我不好评价它，毕竟没有用过。但是从RAD这十多年来大大改进了开发效率，但是在易维护性上不但没有改进，反而有所退步这一方面来看，EOS的易维护性比较可疑。

降低技术门槛很容易诱使技术一般的开发人员使用最易开发的方式进行开发工作——比如在RAD里直接在事件响应里处理业务逻辑，这几乎是必然导致未来的维护工作大大增加——当然，EOS可能与此不同，不过它毕竟出来的时间不长，随着时间的推移，维护问题将逐渐显现。

而提高效率的同时，隐藏了过多的技术细节。如ARI所说：这是很危险的。任何事物都有两面性，构件带来方便的同时，必然带来局限。如果在未来维护时需要涉及细节上的变动，就可能受到很多的制约，增加维护成本。

当然，如令狐所说：一个产品被研发出来，总有它的市场和应用。但是普元目前的宣传方式并不能消除上述的这些疑虑。所以我还是认为，如果普元的EOS真是如他们所说的那么好，最好还是尽量多地发一些技术文章来证明，而不是扯淡。