京淘项目(单点登录系统)

目录

系统设计说明

项目背景

名字描述

项目业务

项目设计

核心业务描述

菜单模块

原型设计

菜单列表页面:

 菜单添加页面

菜单修改页面

表设计

逻辑对象设计

业务测试设计

角色模块

业务描述

添加页面

角色编辑页面

表(roles)设计

测试逻辑设计

部门模块

用户模块

业务描述

原型设计

表设计

测试逻辑设计

日志模块

---

系统设计说明

项目背景

任何一个后端业务系统都会有一个权限管理子系统,这个子系统主要负责对用户进行身份认证和授权,合法用户再有权限的情况下,才可以访问我们系统中的资源,防止恶意用户对资源进行破坏

名字描述

京淘供应链系统中的权限管理子系统

达人购权限管理子系统

动吧旅游系统中权限管理子系统

......

项目业务

项目设计

核心业务描述

菜单管理,部门管理,角色管理,用户管理,日志管理,公告管理...

菜单模块

菜单是资源的外在展现形式,我们所说的资源管理,一般都是通过操作菜单实现的

原型设计

菜单列表页面:

如何理解权限管理?(主要是针对用户访问资源进行鉴权)

如何理解资源?系统中的数据(文档,视频,其他信息等)

如何理解菜单管理?(菜单是资源的外在表现形式,我们是通过菜单操作资源的)

 菜单添加页面

当我们点击添加按钮时,加载添加页面

 点击上级菜单时,可选择当前要创建新菜单的上级菜单

菜单修改页面

 当我们选择某一个菜单,点击修改按钮时,加载修改页面,底层向服务端发送ajax请求,从数据库加载菜单id对应的菜单数据,并呈现在页面

 在编辑页面点击上级菜单时,呈现一个菜单树,内容是底层向服务器发送ajax异步请求从数据库加载的数据

表设计

设计类似有层次的结构的表时,一般都添加一个parentID,用于指向上一级的菜单信息.同时还有一些sort字段,用于排序操作.这儿里的菜单通常是访问资源的一种外在形式,访问资源要特定的权限,通常还会给菜单添加对应的访问权限

逻辑对象设计

Pojo(MenuPojo)

Dao(MenuDao,MenuMapper.xml)

Service(MenuService)

Controller(MenuController)

业务测试设计

### 查询菜单信息
GET http://localhost:8091/menu/

### 根据id查询菜单信息
GET http://localhost:8091/menu/8

###
POST http://localhost:8091/menu/
Content-Type: application/json

{
  "name": "字典管理",
  "url": "/page/sys/zidian_list",
  "type": "1",
  "sort": 19,
  "remark": "城市 ..",
  "parentId": "8",
  "permission": "sys:menu:list"
}

###
PUT http://localhost:8091/menu/
Content-Type: application/json

{
  "id": "157",
  "name": "字典管理",
  "url": "/page/sys/zidian_list",
  "type": "1",
  "sort": 19,
  "remark": "城市 ..",
  "parentId": "8",
  "permission": "sys:menu:list"
}

###
GET http://localhost:8091/menu/treeNodes

角色模块

业务描述

角色是用来描述用户的一个对象,每个用户有不同的权限,权限不同,能够查询的资源也不同

添加页面

在点击角色列表时,角色的授权信息以树状图显示在页面

在添加页面信息中,为角色分配访问菜单的权限,点击添加后,将数据异步提交给服务器,服务器获取到数据后,会将角色自身数据持久到角色表(sys_roles),角色菜单关系数据持久化到角色菜单关系表(sys_menu)

角色编辑页面

当我们点击角色列表中的某一行角色修改按钮时,首先要呈现角色编辑页面,并且异步加载菜单树,最后基于角色Id查询异步查询角色信息,以及角色对应的菜单信息,并更新在页面上

 当我们在页面上修改完数据,点击保存按钮时,将页面数据(角色自身信息,角色菜单关系信息)提交到服务端,服务端回家过数据持久到数据库,具体过程是先更新角色自身信息,然后删除角色菜单原有关系数据,再添加新的关系数据

表(roles)设计

角色表

 角色菜单关系表

思考:

角色表与菜单表关系?

多对多,一个用户有多个查询菜单权限,一个菜单能被多个用户查询

测试逻辑设计

pojo(SysRole)

Dao(SysRoleDao,SysRoleMenuDao,SysRoleDao.xml,SysRoleMenuDao.xml)

Service(SysRoleService,SysRoleMenuService)

Controller(SysRoleController)

测试实现

### 查询角色信息
GET http://localhost:8091/role/?pageCurrent=1&name=工程师

### 添加角色信息
POST http://localhost:8091/role/
Content-Type: application/json

{
  "name": "程序员管理师",
  "remark": "精神鼓励..",
  "menuIds": [115,116]
}

### 根据角色id查询角色权限信息
GET http://localhost:8091/role/58

### 根据角色id更新角色权限信息
PUT http://localhost:8091/role/
Content-Type: application/json

{
  "id": "58",
  "name": "程序员管理师",
  "remark": "精神鼓励..",
  "menuIds": [115,117,118]
}

部门模块

类似菜单模块

用户模块

业务描述

这里的用户为我们的系统登录系统,(假如是后台登录用户信息由管理员添加,用户登录后可以修改自身信息,假如是前台用户则是注册用户),此用户可以有多个角色,当然同一个角色可以授予不同用户,所以用户和角色是一对多关系

原型设计

用户列表页面

我们在主页面点击用户管理时,加载并呈现用户列表页面,然后客户端底层会发起ajax请求,获取用户信息,用户对应的部分信息,并在次页面上进行局部更新,刷新页面

在当前页面可以点击分页按钮查询用户信息,点击启用,禁用修改用户的状态

添加用户列表页面

在用户列表页面,点击添加按钮,先加载用户添加页面,然后异步发送ajax请求,加载数据库中角色信息,并呈现此页面中,

在此页面添加用户信息,点击所属部门时,发送异步请求,查询部门信息,并以树结构方式进行呈现

 用户写好数据后,点击save按钮,向服务段发送aiax异步请求,将用户信息,用户角色关系数据持久化到服务端数据库

用户修改页面

在用户列表页面,选中一个用户,然后点击修改数据,此时加载修改页面,并且向服务端发送ajax异步请求,加载数据库中的信息,并呈现在页面中

 我们在编辑页面修改用户信息,用户对应的部门,用户对应的角色信息,点击save按钮,此时向服务端发送ajax异步请求,将这些信息传递到服务端,服务端收到数据后,将数据持久化到数据库表中,其过程首先是更新用户自身信息,然后删除用户和角色关系数据,并添加新的用户和角色关系数据

表设计

用户表

用户角色关系表

测试逻辑设计

对象设计如下:

Pojo(SysUser)

Dao(SysUserDao,SysUSerRoleDaom,SysUserMapper.xml,SysUserRoleMapper.xml)

Service(SysUserService,SysUserRoleService)

Controller(SysUserController)

测试

### 分页查询用户信息
GET http://localhost:8091/user/?pageCurrent=1

### 禁用用户(携带令牌)
PATCH http://localhost:8091/user/1/0

日志模块