Lei Zhang

时光已逝永不回,
往事只能回味。
... ...
春风又吹红了花蕊,
你已经也添了新岁。

▓▓▓▓▓▓▓▓▓▓▓▓▓▓░ 88%



3Years-2 用户模型

2018-04-04 » 没填完的坑 / 3Years , ACL , Tutorial , 微信开发 , 环境搭建

项目地址:https://github.com/PassionZale/3Years


上一篇,简短的介绍了整个项目的情况,所有项目的起点,都是从设计数据库表结构(即:模型)开始的。

而所有的模型,都是基于业务。

接下来,我会用较多的篇幅来详细描述各个模型如何进行设计。


不管公众号里面的商城如何实现具体业务,你的系统首先都必须有管理后台,因为商城里面大部分展示数据,如分类、商品等,都是从管理后台录入的。

对于管理后台,首当其冲需要解决的,则是用户系统,与之相关的便是用户的 ACL 系统。

用户模型

一个模型,并不代表它只有一张表!

对于用户模型来讲,它的复杂程度,取决于系统对权限的细分程度。如果系统不需要区分用户权限,那么一张用户表即可搞定所有事情。

我在建表时,有一个习惯,如果一个模型需要多张表来支撑,那么就为这些表定义一个“表前缀”;

另外一个习惯,便是每张表除非真的没必要,我都会加上“创建时间”、“修改时间”两个字段。

“用户”意味着管理后台的“授权认证”,只有通过“认证”,才会被“授权”,进而能在后台对其他“权限允许”的模型进行操作,因此我将这个前缀定义为:auth

(用户表)auth_user

1. is_superuser,超级管理员标识,默认为 0。有了它,在权限编码过程中,我们便只需要通过判断这个字段是否为 1,即可为该用户打开所有权限,而不用再去角色、权限表中查询其拥有的权限集合,再进行判断了。

2. is_active,账号活动标识,默认为 1。当其为 0 时,便表示该用户被禁用了,无法登录至管理后台。


(角色表)auth_role


(权限表)auth_permission


(多对多)auth_user_role


(多对多)auth_role_permission


一点补充

至此,整个用户模型构建完毕,并且通过 auth_user_roleauth_role_permission 建立了 MANY-TO-MANY 关系。

更多的 ACL 详细构建思路,可以参考我的另一篇文章:ACL - Access Control List

展开选填信息