我的网站的后台管理的结构图。

不知道这个能不能放在首页,不行的话我会测下来的。
另外这个算不算是一种架构呢?
欢迎大家多多批评指教!
我的网站的后台管理的结构图。
我的网站的后台管理的结构图。

说在前面:

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%以上的功能。
可以说使用这个后台,不需要修改代码,只需要更换配置文件就可以应用在数据结构完全不同的网站。


网站结构图
上一篇:as3 操作excel表格


下一篇:Information Retrieval 倒排索引 学习笔记