我的WEB设计契约--数据库篇
WEB开发中数据库是一个重头工作.
良好的设计对开发工作至关重要.
我一直在寻求一种简洁的,规范化的,可代码流程化的设计.
今天终于让我摸索到了.
数据库的表这样设计
- 表名,字段名全部小写表b的字段b1数据如果来自表a的字段a1,这样命名b1:a_a1,目的为提交数据合法性校验提供便捷如果数据库支持备注coment.那就把校验规则直接写入coment,至于写法,看个人的习惯了,当然这个规则最终是要导出为不同的语言校验代码的.
数据库数据提交格式(数据以关联数组的形式提供)这样定义
- 关联数组的key表示字段,value表示相关参数
key小写为SELECT/UPDATE的WHERE条件key大写为UPDATE/INSERT的field值对定义key混写为SELECT的返回字段,实际工作当中,我是用特殊的key==*来处理的,这样方便 key==""为扩展的SQL语句,如limit,order等,当然里面还有细节的设计
要实现这个接口并不难,因为这个接口的含义很明确,可以适用常用的SQL语句请求,当然这个接口也不是万能的,比较复杂的SQL语句行为还需要特殊的处理
?
数据库操作类的接口设计
- 首先应该根据业务逻辑和上面的格式定义设计一个数据有效性检查前端代码,数据检查通过后操作类根据上面的格式定义设计就可以自动的生成常用的SQL语句
业务逻辑问题(也就是接口设计说的1)
- 根据用户角色,设计函数名一致,内容不同的接口函数前台提交的数据要有办法和接口函数对应的逻辑,这个简单就是一个参数(action)问题
这一点举个php的例子
if($ValidateCode)//如果验证通过了
就行了,没有通过验证的话运行期就不会有对应action函数,当然错误处理是另外的事情了.
同样的道理可以根据用户角色的不同设置接口函数(action)的执行体,或者干脆有没有这个action函数.
同样的道理可以根据这种方法以不同的状态标志来定义action函数
其实这种方法也就是根据运行状态判定action接口了,你可以把session中的重要状态做为判定条件
经过这样的契约,前台的action数据提交到后台后经过这些环节
- 前端的统一处理,比如session,cookie,检验验证码等根据action调入相应的模块模块根据运行状态定义action接口函数action提交数据的有效性检查,这个复杂了,看应用了执行action接口函数
那action接口函数的内容是什么呢?当然主要的是负责如何输出以及相关的行为处理了,不过重头的数据库SQL操作却简单了.几乎把action数据完全传个数据库操作类就完事了.(当然复杂的业务总是要单独处理的)
?
估计看这篇文章的人99%的都是一头雾水.先不管看明白没有,首先会问为什么这么设计?
你仔细看完我的文章,回头想想,如果你参考我的方法做的话,你会发现:
我提供的是一种策略,一种契约,但绝不是一个框架库
授人以鱼 不如授之以渔
而且就算我把我的代码给你,恐怕有用的仅仅是那个数据库接口类的设计,其他的对于你的应用都没有用,因为那些都要根据业务逻辑定制书写.用任何框架库都避免不了要写的代码.
有点框架库无用的味道
1 楼 caiceclb 2008-12-06 参考了，谢谢