另外这个算不算是一种架构呢？
欢迎大家多多批评指教！
说在前面：
1、 配置文件并不是 web.config文件，显然要往配置文件里放很多的东西，web.config有点小了，也不方便。
也不是XML文件，因为我还不太会使用XML，如果使用XML的话，又要都读出来放在内存里以提高访问速度，比较占用内存。其实是一个Access数据库。
2、 蓝色空心箭头表示数据的流向；
桔黄色的是查询控件向分页控件提供查询条件；
黑色的实心箭头是配置文件向控件提供控件所需要的属性；
蓝色的实心箭头表示点击树的节点可以进入的页面。
3、 数据访问层和网站里用的是完全一样的，分页控件略有差别，
网站里的是URL分页，而这里的是PostBack分页。
4、显示数据列表的页面和添加修改数据的页面，在项目里只会出现一次。无论是新闻管理还是产品管理都是用的相同的页面。栏目再多也就是这两个页面。增加栏目只需要修改配置文件！
这个是我现在用的网站后台管理的结构图，已经有两年多的历史了，整理了一下拿出来请大家批批。
这个是我现在用的网站后台管理的结构图，已经有两年多的历史了，整理了一下拿出来请大家批批。
功能：
1、 可以实现数据的浏览、查询、添加、修改、删除等功能。
2、 权限管理。
3、 操作记录。
4、 出错记录。（其实这个是数据访问层的功能）
特点：
1、 控件化，这个看图就知道了，几乎就是由控件“搭”起来的。
2、 代码少，都是调用控件，代码自然会很少。
3、 页面少，一般的情况（主从表除外）两个页面就够了，一个页面用来显示数据列表（包括查询、删除），一个页面用来添加、修改数据。因为控件所需的属性都写到了配置文件里面。
4、 有专门的程序来维护“配置文件”，不用手动的改来改去了。
5、 SQL语句和程序的分离。以前发的帖子里有人回复说，直接在UI层里写SQL不好。我也觉得不太好，于是就完全分离出来。通用的部分放在了控件里面，变化的（表名、字段名）放在了配置文件里面。
6、便于维护。比如一开始添加新闻的地方只有新闻标题、新闻内容两个字段，几天以后又要增加编辑、来源。修改数据库后，只需要修改配置文件就可以了，不需要修改代码，更不需要重新编译。而修改配置文件也只需要轻点几下鼠标，因为有一个配置文件的维护程序。
配置文件里的内容：
1、分页控件的属性。每一个页面都对应不同的表，所以呢需要把这些属性都放到配置文件里面。
2、字段的描述。字段的类型、使用什么控件（文本框、下拉列表或是其他），外观描述（宽度、字符数等），相关的SQL语句（比如下拉列表框需要的绑定数据的SQL语句）。
3、表单控件的属性。这个就比较多了，表单控件要绘制出文本框之类的控件，好让用户来输入数据，然后呢收集这些数据进行前台的判断，后台判断，组合成SQL语句（或者给存储过程的参数赋值），提交给数据访问层，最后保存到数据库。也就是说要把字段的描述信息都放在这个配置文件里面，然后是哪个页面需要哪些字段，也就是对应关系。内容还是比较多的，放在XML里面还真不知道怎么做（XML不太熟呀。）
3、查询控件，这个和表单控件差不多。其实时在作表单控件的时候突然想到的，可以利用表单控件的原理顺便作一个查询控件呀。
4、显示数据的控件，那个页面需要显示那些字段，td的宽度，居中居右还是居左等信息。
缺点：
1、 有很大的局限性，放之四海而皆准是不太可能了（至少现在是这样）。我的目的是小而精，自己用着舒服就行，用不到的功能就暂时不加，以后用到的时候再说。:)
2、 并不能完成所有的功能，涉及不到的还是要单独写页面的。比如权限分配，主从表的添加、修改等。
PS：
什么您说我的这个只能应对简单的添加修改的操作。
是呀，现在做的是网站，逻辑很简单了，这个后台可以完成90%以上的功能。