项目（程序、代码）横着切是层，竖着切是模块，您是如何切的呢？我是这样切的。请看下图，好像有点乱:)
自定义控件，好像在正常的情况下，只能管UI的部分，其他的（逻辑呀、SQL语句、数据访问）就不要管了，而我这里呢，偏偏要多管闲事，偏偏要把SQL语句也放到自定义控件里面，于是遭到了好多人的反感。可是我一点悔改的意思都没有，于是大家都觉得我很固执。我只是想写程序的时候方便一些。我自己有一点想法，写出来请大家看看，人这一辈子还能做点什么呢？好多人看我的帖子，很感谢大家，无论是批评的、建议、赞成的、支持的、得到一点启发的，我都要感谢！没有大家的支持，我也不可能写出来这么多，当然有一些写得不怎么地，占用了大家宝贵的时间。不过大家一起讨论，可以让一些问题更明显，避免其他人走弯路。即使我的想法是错误的，那么也是可以证明有一种方法是行不通的，其他人就不要再尝试了。不过我还是要继续的，呵呵。
DbHelp基于ADO.Net 2.0的访问数据库的东东，就是对ADO.Net 2.0的一些操作的封装，以便于可以更方便的访问数据库，就是我的数据访问函数库。托ADO.Net 2.0的福，支持多种数据库。他本身是不包含任何SQL语句的，他只负责传递SQL语句和记录集，记录集的载体是string、string[]、DataTable、DataSet、特定结构的类，不支持自定义的实体类。
为什么要有一个Help呢，就是因为直接使用ADO.Net 不太方便，所以又对他进行了一下封装，让操作更方便一些。
我看到一些项目里的数据层的代码，里面包含了“ADO.Net 的操作”、添加、修改数据的SQL语句、存储过程的参数，删除数据的SQL语句，显示数据的SQL语句，有的还是实现了分页显示数据的SQL语句和存储过程的参数。我觉得把这些都一股脑的放在了一起（同一个.cs文件），有点一刀切的感觉。把他们都放在了一起，恐怕是因为他们都是和数据库相关的，或者说都有SQL语句（包括存储过程、存储过程的参数）的成分，于是就放在了一起，这个划分方式未免太粗糙了吧，一点都没有精工细作的感觉。如果真的是这样的话，那倒是方便了。
术业有专攻、分工合作，各自研究自己的才会更专业，对吧？所以我把添加、修改的SQL交给了表单控件，显示数据用得SQL语句交给了分页控件，这样各做各的，各自研究自己的功能，更好的去实现，这样才能够更好的发展！代码才能更简洁！
上面的切法有交叉的部分，那就是SQL语句，这个放在哪里呢？这个可能是最大的争议吧。为什么会有争议呢，因为他是一个“黏合剂”。程序要想和数据库打交道，必须使用SQL语句，所以他首先是程序与数据库之间的“黏合剂”。
表单控件，这个还没有升级完成，我现在用的是。.net1.1的，升级后会基于.net2.0，内部代码也会完全整理一便。
分页控件基本完成了，当然还有许多小功能没有加进来，原因就是我现在工作中还在用vs2003，没有升级到vs2008。
我的应对多种数据库的思路，以分页控件为例。
三层里面应对多种数据库是要先定义一个IDAL，然后再去实现一个SQL Server专用的DAL，在实现一个Orcale专用的DAL。而一些人根本不去管哪些代码是相同的，哪些代码是不同的。IDAL里面完全是空的，里面只有定义，即使有相似（相同）的代码也绝对不会放在IDAL里面，因为没有那份心思去想到底哪些是一样的，哪些是不一样的，哪些虽然目前是一样的，但是以后可能就不一样了。因为区分不了，所以干脆各放各的，互不干扰。管你相同不相同呢，一种数据库写一套实现接口的代码，一面互相影响。于是代码量就成倍的增加，修改量也成倍的增加，不过这也挺好的，因为提供了更多的就业岗位。因为人少了改不过了。
