实体类与电梯

     我们先假设一种情况，一个开发商想盖一座大楼（假设30层吧），先要弄一个设计图纸呀，没有设计图纸怎么盖楼呢？设计图纸的其他部分我们就先不管了，只看看电梯的这一块的情况。一开始要选用电梯公司A的电梯，于是设计图就根据A的电梯设计电梯间。图纸设计完了，开始施工，一切都很顺利，很快大楼就盖起来了，大家都很高兴，下面要开始安装电梯了。但是以外发生了。

     原来要采用电梯公司A的电梯，但是由于种种原因不能采购了，于是改用了电梯公司B的电梯，拿到电梯的技术参数大家傻眼了，怎么B的电梯要比A的电梯长30里面？这样太长了，电梯间里面放不下去呀？怎么办？楼都盖好了，难道要修改电梯间，把每一层的电梯间都加宽吗？这改动量也太大了呀，如果因此影响了整体的稳定性怎么办呀？那么改电梯间不上上策，看看其他电梯公司的电梯有没有适合的吧，换电梯还是比较方便的呀，这才是上策！

     但是由于电梯间已经设计好了，那么选择电梯的范围就缩小了，尺寸不匹配的，性价比再好也不能选。这个就很被动了。如果所有的电梯公司生产的电梯，外观尺寸都是一样的，那该多好呀。这样设计的时候就不用考虑将来采用什么样的电梯了，因为所有的电梯的外观尺寸都是按照一个标准生出来的，不用担心电梯间设计出之后，电梯放不进去的情况。

     对于电梯公司来说，这也是一件好事，只要按照这个标准生产电梯，那么都不用担心生产出来的电梯安装不上的情况了。

     ps：这个就是所谓的针对接口编程吧。不过这里并不想讨论接口编程的问题，只是写到这里了，突然想到的。这里想说的是实体类。

     好了故事变好了，我不是搞建筑的，不知道这个故事编的是否合理。我想说的是，在三层里面，实体类变化了，每一层如何应对的事情。

     我不愿意接受三层的形式，一大原因就是当实体类变化的时候，基本每一层都需要改代码，就像大楼里的电梯变长了，每一层的电梯间都要修改一样。而我又没有想到什么好的方式来应对（在使用三层形式的范围内），所以我就没有用三层的这种形式开发项目。

     针对接口编程，看起来很好，那么如何来实现呢？这个我就不知道了，因为对接口的了解并不多，对实体类在各种业务需求下会变成什么样子，“资料”掌握的也不多。看了前两天园子里的一篇post，也没感觉出来有什么优势，可能是我还没有看到真正的好的针对接口编程的例子吧。

     所以我只好采用笨招了，定义一个ColumnsInfoBase  类（这里有介绍）来存放需要的信息，而ColumnsInfoBase  本身是固定的（属性不变），就好像限定了长宽高的电梯一样。这样每一层都针对这个固定的ColumnsInfoBase  来编写代码，数据层和UI层的代码就固定下来了，逻辑层的代码变化也不大。单纯的字段变化就可以完全不用修改逻辑层了，当然数据层、UI层也是不需要修改的。只有当业务逻辑变化的时候才有可能需要修改逻辑层的代码，这时候数据层、UI层的代码还是不需要修改的。