我的WEB设计契约--数据库篇

WEB开发中数据库是一个重头工作.

良好的设计对开发工作至关重要.

我一直在寻求一种简洁的,规范化的,可代码流程化的设计.

今天终于让我摸索到了.

数据库的表这样设计

1. 表名,字段名全部小写
2. 表b的字段b1数据如果来自表a的字段a1,这样命名b1:a_a1 ,目的为提交数据合法性校验提供便捷
3. 如果数据库支持备注coment.那就把校验规则直接写入coment ,至于写法,看个人的习惯了,当然这个规则最终是要导出为不同的语言校验代码的.

数据库 数据 提交格式(数据以关联数组的形式提供)这样定义

1. 关联数组的key表示字段,value表示相关参数
   
2. key小写 为SELECT/UPDATE的WHERE条件
3. key大写 为UPDATE/INSERT的field值对定义
4. key混写 为SELECT 的返回字段,实际工作当中,我是用特殊的key==*来处理的,这样方便
5. key==""为扩展的SQL语句,如limit,order等,当然里面还有细节的设计

要实现这个接口并不难,因为这个接口的含义很明确,可以适用常用的SQL语句请求,当然这个接口也不是万能的,比较复杂的SQL语句行为还需要特殊的处理

 

数据库操作类的接口设计

1. 首先应该根据业务逻辑和上面的格式定义设计一个数据有效性检查前端代码,数据检查通过后
2. 操作类根据上面的格式定义设计就可以自动的生成常用的SQL语句

业务逻辑问题(也就是接口设计说的1)

1. 根据用户角色,设计函数名一致,内容不同的接口函数
2. 前台提交的数据要有办法和接口函数对应的逻辑,这个简单就是一个参数(action)问题

这一点举个php的例子

if($ValidateCode){//如果验证码通过了
if($userrole==0){//根据用户角色的不同设置接口函数(action)的行为
  function query(){
  something;
  }
}
if($userrole==1){
  function query(){
  something;
  }
}
}else{
function foo(){}
}

 解释,其实对于验证码来说,完全可以统一进行验证,没有必要在action函数里进行验证,这样的话,定义action函数的时候,如果某action函数需要验证后才能执行的话,那就把这些函数定义全都包在

if($ValidateCode)//如果验证通过了

就行了,没有通过验证的话运行期就不会有对应action函数,当然错误处理是另外的事情了.

同样的道理可以根据用户角色的不同设置接口函数(action)的执行体,或者干脆有没有这个action函数.

同样的道理可以根据这种方法以不同的状态标志来定义action函数

其实这种方法也就是根据运行状态判定action 接口了 ,你可以把session中的重要状态做为判定条件

经过这样的契约,前台的action数据提交到后台后经过这些环节

1. 前端的统一处理,比如session,cookie,检验验证码等
2. 根据action调入相应的模块
3. 模块根据运行状态定义action接口函数
4. action提交数据的有效性检查,这个复杂了,看应用了
5. 执行action接口函数

那action接口函数的内容是什么呢?当然主要的是负责如何输出以及相关的行为处理了,不过重头的数据库SQL操作却简单了.几乎把action数据完全传个数据库操作类就完事了.(当然复杂的业务总是要单独处理的)

 

估计看这篇文章的人99%的都是一头雾水.先不管看明白没有,首先会问为什么这么设计 ?

你仔细看完我的文章,回头想想,如果你参考我的方法做的话,你会发现:

我提供的是一种策略,一种契约,但绝不是一个框架库

授人以鱼 不如授之以渔

而且就算我把我的代码给你,恐怕有用的仅仅是那个数据库接口类的设计,其他的对于你的应用都没有用,因为那些都要根据业务逻辑定制书写 .用任何框架库都避免不了要写的代码.

有点框架库无用的味道

评论

1 楼 caiceclb 2008-12-06  

参考了，谢谢