今天开会，又决定把JDBC+Stateless SessionBean的数据存取方案改成EntityBean的方案。这个意味着我的模块要重新设计。这件事意味着两个教训(都是以前犯过的)：1. 不要以为自己比别人牛。 当初我们设计这个模块的时候，选用EntityBean，就是觉得EntityBean的配置和部署太过繁复，而且EJB1.1不支持local interface，导致复杂数据操作的效率下降。而且规定object-schema mapping也不比JDBC+SSB简单多少。谁知道设计起来才发现，一旦要处理复杂点的关系，代码自然就复杂乐。最后发现我们的设计重复了很多EntityBean本来就有的功能，比如物件级别的缓存(我自己写了个single-write-multiple-write的缓存模块，浪费时间啊 ), 可配置的关系映射，和多级代理的设计模式。。。事后仔细一想，人家Sun的程序员比我们牛多了，未必还没写过手工处理的数据存储啊？当然是问题多多，才发明了EntityBean的解决方案三，我们却天真地以为自己比别人牛B，完全忘了Linus解释为什么Linux内核不用C++写的名言：being there, done that。 其实这个教训以前就有过。以前上文件组织的课时，放着一个小时就可以写好的常用实现方法(linked bucket)，非要去实现所谓支持最大灵活性的Extendable Hashtable, 结果足足写了两天，还写得不好。其实Eric在他的
blog里也提到他曾犯的类似错误，我怎么就没有往心里去呢？2. 这个比较老套。就是磨刀不误砍柴功。项目刚开始的时候，无数的书都说了有复杂关系的数据存取用EntityBean不错，但我居然没仔细想过别人为什么那样坚持，也没有深入调查，全忘了古训：事豫则立，不豫则废。
发表于 @ 2004年06月25日 10:31:00|评论(loading...)|编辑