糟糕的设计

       不要去弄脏构造器方法！

                         ---------------2009-02-24

 

        这是来自自己最近的项目Salesys的一个经验之一。坦白说，在这个项目，还有以前的几个项目中糟糕的设计有很多，这个只是其中之一。

        在Salesys的一个很大的特点就是大部分的模块在开始页面都有一个信息列表，用于显示这个模块的主要信息。就像这样：

 

       在我们的代码设计中（其实根本就没进行设计），这个信息列表是保存在一个 list中的。很自然的，我们会在backing bean 里面为这个属性写构造器方法。顺便说一下，Salesys 是JFS+EJB架构的。现在的问题是我们要去调用EJB里面的方法来从DB读取这些数据。接下来自己做了一个很业余的决定，改写get方法，让get方法来调用EJB，而忘了用户触发这个事件的方法。

        而这个该死的决定带来的后果是：当我们要分页显示这些数据时，程序每次都去读数据库，到后来程序就会变的很慢很慢。更该死的是我们在所有模块都快写完的时候才发现这个问题。于是我们采取了一个补救措施，在get方法里面加一个判断，当list 等于null的时候才去读数据库。

        我们以为问题解决了，而忘了还要做那些该死的添加，删除，编辑等操作。就这样新的问题来了，当我们向DB添加了一条数据的时候，并不会在这个信息列表里面显示出来。因为我们的list不为null。于是我们又去修改我们的添加，删除，编辑等方法。  等到业务上的方法加进来的时候，我们又发现我们的get方法还不够用，于是又加了写代码进去。

        经过不停的给代码打补丁，程序终于能正确的显示页面了。但是已经不那么稳定了，代码的意图也很难看懂了。

        后来我不断的问自己，为什么当时不在响应用户操作的方法中来读写DB，而让构造器方法只有一行代码呢。这样代码的意图不是很清楚，程序不是更稳定？