CSDN博客

img g9yuayon

又犯了不该犯的错误

发表于2004/6/25 10:31:00  3060人阅读

今天开会,又决定把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不错,但我居然没仔细想过别人为什么那样坚持,也没有深入调查,全忘了古训:事豫则立,不豫则废。 

0 0

相关博文

我的热门文章

img
取 消
img