忘记说范围了，讨论范围：以数据为主的项目，信息管理方面的项目。
我们先假设一个场景（可能现实中并不存在，只是一个想法），一家超市，有柜台，有仓库。进货的时候需要往仓库里放货物，卖货的时候需要从仓库里提取货物运到柜台。（好像都是废话，呵呵）
那么货物如何进出仓库呢？我们需要一条传送带，可以把货物传送到仓库里面，也可以把货物从仓库传送到柜台。但是我们卖的货物种类很多，有冰箱、彩电、洗衣机，有锅碗瓢盆，还有瓜果梨桃。呵呵货物挺全的，而且卖什么货物还不一定，根据市场情况来定。可能增加某些货物，也可能有些货物就不卖了。
仓库和柜台就先不说了，我们来看看这个传送带的情况。我们有两种选择。
1、专用传送带。
就是说如果想传送彩电，就要用彩电专用传送带，这种传送带专门彩电电设计，有凹槽设计正好可以放进一个彩电，保证在传递过程中的绝对安全，还增加了防震等特殊处理，可谓传送彩电的绝佳选择。可是缺点也是显而易见的，只能传送彩电，冰箱是不行的，手机也是不行的。如果要传递冰箱的话，那么就要选用冰箱专用传送带，类似的还有手机传送带，水果传送带，等等。
由于卖的货物的种类很多，采用这种方式的话，那么就要购进很多的传送带，如果增加货物的种类，那么就要增加传送带，如果哪种货物不卖了，那么对应的传送带就没有用处了。
2、通用传送带。
优点就是什么都可以传送。冰箱、彩电、洗衣机，锅碗瓢盆，瓜果梨桃都可以放在上面传递，这样就大大的节省了成本。缺点嘛就是没有专用的凹槽，货物放上去有一点咣当，呵呵，但是也可以保证货物在传递过程中是不会掉下去滴。
如果您是超市的老板，您会选择哪一种方案呢？
言归正传说程序。
很明显，上面的例子中的仓库就是数据库，柜台就是客户看到的页面。页面一般都是客户来决定的，如何摆放等，程序员基本没有什么控制权（就是说，怎么改页面，我们基本是说了不算的）。数据库呢也是要根据业务需求不断地变化的，如果数据库可以不用变化的话，那么好多争论也就不存在了吧。当然如何变化我们也是很难预测的。就好像是天气，我们可以预测，但并不是每次都准。到底下不下雨还得看大自然，呵呵。
那么就剩下中间的“传送带”了，一般客户是不会管这一块的，是可以有我们来作主的。
专用传送带呢，就是实体类吧（包括CRUD的实现）。看到书了，就要class book出来，然后实现book的CRUD；看见什么了就class一个出来，呵呵。什么您说我这是错误的，要先抽象，抽象了才行。嗯对，但是抽象之后传送带的种类并不能变成一个，只是减少了一些，比如彩电可以和电脑显示器（CRT）的用一个，各种品牌的手机共用一种，蔬菜用一种。
通用传送带就是我的思路，不管是什么货物，就是一种传送带，通吃！
通用传送带在我的程序里面是由数据访问函数库、分页控件、表单控件、查询控件等组成的。这样就省去了，新增加一个微波炉，就得增加一个微波炉传送带的麻烦了。增加货物不用修改传送带，那么货物的尺寸、外形有了变化，自然也不用修改传送带的。就是说当业务需求有了变化，我们修改一下数据库，改一下UI就可以了，中间的“传送带”是不用修改的。其实如果用表单控件的话，UI也是不用修改的，改配置信息就可以了。
那么“传送带”传递的是什么呢？SQL语句和记录集。当然SQL语句并不是完全有外部提供，实际上大部分的SQL语句都是在控件内部拼接（根据控件的属性）的。
记录集分为两种，多条记录的就直接放在DataTable里面，这么方便为什么不用呢？
一条记录的可以放在一个特定的class里面。表单控件就定义了一个class，来存放信息。他不只存放字段名称、字段的值，还有字段类型、字段大小、控件类型等信息，通过这些信息来描绘UI，拼接SQL语句（参数化的），添加存储过程的参数等，最后再交给数据访问函数库，由他（还要通过ADO.net）转给数据库执行SQL语句。
这样这些控件和数据访问函数库就组成了一个传送带（或者是一个通道），来传递SQL语句和记录集。这样我们就只剩下数据库的设计了。数据库设计完毕之后，通过这些控件（还有配置信息），可以很快的实现功能，客户可以试用一下，完成数据流。
数据流流起来之后，才能看到数据库的设计是否合理，才能尽快确认数据库的设计是否合理。