从C/S模式下的三层架构说起

引子
网友问：
很多的参考书目中都是把对数据库的操作都是独立于文档类封装成数据库类。基本上是对应一个表就要建立一个类，在其中实现“增、删、改、差”的功能。代码看起来比较庞大，当然通过类的划分模块比较的清楚，使用时通过数据库类的对象的简单的函数调用就可以了。（不用传完整的SQL语句，仅仅是用到的参数而已）

按照OO的思想，我也感觉书上的方法要合理一些，但是就是太麻烦了，还是传SQL语句的方法比较习惯一些。

各位高手们、你们一般是怎么处理的、随便说说这样处理的好处。谢谢！

作者答：
我也同意书上的做法。目前我们项目涉及到的数据库比较简单，因此一般我都封装到一个类中。类的成员变量只有一个，那就是数据库连接m_pConnection。其它的都是函数。如果数据库比较复杂的话，我会派生一些子类用于处理不同的表。
这样封装的最大好处，我认为是开发方便，可以说是实现了三层模式：将界面、数据库接口和数据库开发完全分开，做界面的人不用关心数据库，只需要调用相应的接口函数就可以了。作数据库接口的人只需要关心封装类中与数据库的交互就可以了，做数据库的人只需要做好存储过程，触发器之类的就可以了。这样可以并行开发，提高效率

网友问：
比较困惑点的就是如果分工分明确的话、严格按照三层模式的结构来作并且的确分工比较明确的话这样肯定是有好处的。

但是实际的开发过程中，我所遇到的是数据库的结构要自己设计、存储过程和触发器也要自己写。代码中对数据库的操作也都是自己写的。就是UI层、控制层、业务逻辑层也都是自己写的。写成类的话感觉负担比较大。一个一个的写类反而感觉给自己增添麻烦呀。这样划分不知道还有没有什么特别值得提倡或有益处的地方！！

请大侠在随便讨论一些，谢谢！

作者答：
你这个问题是一般的编程人员都会想到的。做这么多类，好像有点重复性的工作啊。但是，我们要想到的是程序的可重用性和可维护性。虽然我们开发时有些负担，但是以后的升级维护将非常方便。否则，以后的升级维护将是非常困难的事情。这一点必须注意。
只要我们将三层之间的接口预先定义好，这样就相当于我们将项目拆分成了三个零件，零件之间的接口已经定义好了，那么剩下的只需要三个零件分别开发了。如果那个零件以后要升级或者修改，那么涉及范围将只是这个零件而已。否则，你修改一个功能，可能的影响范围将很大，造成升级和维护的困难。
类的好处就是封装性，内部的问题与外界无关，这就是它的好处。所以定义类的时候，我的建议是不要定义公共的成员变量。所有成员变量都是私有或者保护性，增加Get/Set接口。这样做，可能又会向你所说，是不是太麻烦一点了？但如果你考虑到以后维护的方便，这点工作还是值得去做的。
我们的项目为什么做不好，问题不在第一次开发的时候，而是当用户需求有所变更，程序有错误发生时，我们的程序缺乏灵活性，往往导致程序的很多部分要重做。因此，可维护性和可重用性是非常重要的。