我是歌谣 放弃很容易 但是坚持一定很酷
1前言
本文根据自己工作经历编写，若有不合理之处，欢迎吐槽
2定义
后台管理系统什么 对一个页面进行增删改查 是不是有点像，不重复定义
3第一次接触后台管理系统
第一次接触后台管理系统是某b站的一个后台管理系统（Vue+Element 实现电商管理系统）
那时候还是很努力的去跟着视频编写
当时也是认真编写完成这个后台管理系统
现在已经找不到那个代码了 当时换了电脑 代码就丢失了
反正是b站的视频学习所得
3.1原始版后台管理（Vue+Element电商管理系统）
为什么要说这是最原始版的管理系统呢
因为相对于后面的代码比较简单
3.1.1项目演示
项目演示就是一个标准的一个后台管理 包括用户管理 权限管理 商品管理页面什么的 相对来说还是非常的简单易懂
3.1.2目录结构
看完这个布局 当初还是觉得有点东西的 现在想想就是简单的单页面开发 所有的接口调用初始化生命周期里面 会引入一个echart和富文本相对来说还是复杂一点 基本全都是单页面开发样式和调用接口
3.1.3接口文档
每一个系统都有自己的一个接口文档 接口文档大多是按照restful规范进行设计的 如果不按照这个来实现也是可行的 具体看你个人 这里就拿出一部分接口文档增删改查用来做展示而已
-
## 1.3. 用户管理
-
-
### 1.3.1. 用户数据列表
-
-
- 请求路径：users
-
- 请求方法：get
-
- 请求参数
-
-
| 参数名 | 参数说明
| 备注 |
-
| -------- | ------------
| -------- |
-
| query | 查询参数
| 可以为空 |
-
| pagenum | 当前页码
| 不能为空 |
-
| pagesize | 每页显示条数
| 不能为空 |
-
-
- 响应参数
-
-
| 参数名 | 参数说明
| 备注 |
-
| --------- | ------------
| ---- |
-
| totalpage | 总记录数
| |
-
| pagenum | 当前页码
| |
-
| users | 用户数据集合
| |
-
-
- 响应数据
-
-
``
`json
-
{
-
"data": {
-
"totalpage": 5,
-
"pagenum": 4,
-
"users": [
-
{
-
"id": 25,
-
"username": "tige117",
-
"mobile": "18616358651",
-
"type": 1,
-
"email": "tige112@163.com",
-
"create_time": "2017-11-09T20:36:26.000Z",
-
"mg_state": true, // 当前用户的状态
-
"role_name": "炒鸡管理员"
-
}
-
]
-
},
-
"meta": {
-
"msg": "获取成功",
-
"status": 200
-
}
-
}
-
`
``
-
-
### 1.3.2. 添加用户
-
-
- 请求路径：users
-
- 请求方法：post
-
- 请求参数
-
-
| 参数名 | 参数说明
| 备注 |
-
| -------- | --------
| -------- |
-
| username | 用户名称
| 不能为空 |
-
| password | 用户密码
| 不能为空 |
-
| email | 邮箱
| 可以为空 |
-
| mobile | 手机号
| 可以为空 |
-
-
- 响应参数
-
-
| 参数名 | 参数说明
| 备注 |
-
| -------- | -----------
| ---- |
-
| id | 用户 ID
| |
-
| rid | 用户角色 ID
| |
-
| username | 用户名
| |
-
| mobile | 手机号
| |
-
| email | 邮箱
| |
-
-
- 响应数据
-
-
``
`json
-
{
-
"data": {
-
"id": 28,
-
"username": "tige1200",
-
"mobile": "test",
-
"type": 1,
-
"openid": "",
-
"email": "test@test.com",
-
"create_time": "2017-11-10T03:47:13.533Z",
-
"modify_time": null,
-
"is_delete": false,
-
"is_active": false
-
},
-
"meta": {
-
"msg": "用户创建成功",
-
"status": 201
-
}
-
}
-
`
``
-
-
### 1.3.3. 修改用户状态
-
-
- 请求路径：users/
:uId/state/
:type
-
- 请求方法：put
-
- 请求参数
-
-
| 参数名 | 参数说明
| 备注 |
-
| ------ | --------
| ------------------------------------------- |
-
| uId | 用户 ID
| 不能为空`携带在url中` |
-
| type | 用户状态
| 不能为空`携带在url中`，值为 true 或者 false |
-
-
- 响应数据
-
-
``
`json
-
{
-
"data": {
-
"id": 566,
-
"rid": 30,
-
"username": "admin",
-
"mobile": "123456",
-
"email": "bb@itcast.com",
-
"mg_state": 0
-
},
-
"meta": {
-
"msg": "设置状态成功",
-
"status": 200
-
}
-
}
-
`
``
-
-
### 1.3.4. 根据 ID 查询用户信息
-
-
- 请求路径：users/
:id
-
- 请求方法：get
-
- 请求参数
-
-
| 参数名 | 参数说明
| 备注 |
-
| ------ | --------
| --------------------- |
-
| id | 用户 ID
| 不能为空`携带在url中` |
-
-
- 响应参数
-
-
| 参数名 | 参数说明
| 备注 |
-
| ------- | --------
| ---- |
-
| id | 用户 ID
| |
-
| role_id | 角色 ID
| |
-
| mobile | 手机号
| |
-
| email | 邮箱
| |
-
-
- 响应数据
-
-
``
`json
-
{
-
"data": {
-
"id": 503,
-
"username": "admin3",
-
"role_id": 0,
-
"mobile": "00000",
-
"email": "new@new.com"
-
},
-
"meta": {
-
"msg": "查询成功",
-
"status": 200
-
}
-
}
-
`
``
-
-
### 1.3.5. 编辑用户提交
-
-
- 请求路径：users/
:id
-
- 请求方法：put
-
- 请求参数
-
-
| 参数名 | 参数说明
| 备注 |
-
| ------ | --------
| --------------------------- |
-
| id | 用户 id
| 不能为空 `参数是url参数:id` |
-
| email | 邮箱
| 可以为空 |
-
| mobile | 手机号
| 可以为空 |
-
-
- 响应参数
-
-
| 参数名 | 参数说明
| 备注 |
-
| ------- | --------
| ---- |
-
| id | 用户 ID
| |
-
| role_id | 角色 ID
| |
-
| mobile | 手机号
| |
-
| email | 邮箱
| |
-
-
- 响应数据
-
-
``
`json
-
/* 200表示成功，500表示失败 */
-
{
-
"data": {
-
"id": 503,
-
"username": "admin3",
-
"role_id": 0,
-
"mobile": "111",
-
"email": "123@123.com"
-
},
-
"meta": {
-
"msg": "更新成功",
-
"status": 200
-
}
-
}
-
`
``
-
-
### 1.3.6. 删除单个用户
-
-
- 请求路径：users/
:id
-
- 请求方法：delete
-
- 请求参数
-
-
| 参数名 | 参数说明
| 备注 |
-
| ------ | --------
| -------------------------- |
-
| id | 用户 id
| 不能为空`参数是url参数:id` |
-
-
- 响应参数
-
- 响应数据
-
-
``
`json
-
{
-
"data": null,
-
"meta": {
-
"msg": "删除成功",
-
"status": 200
-
}
-
}
-
`
``
-
-
### 1.3.7. 分配用户角色
-
-
- 请求路径：users/
:id/role
-
- 请求方法：put
-
- 请求参数
-
-
| 参数名 | 参数说明
| 备注 |
-
| ------ | --------
| -------------------------- |
-
| id | 用户 ID
| 不能为空`参数是url参数:id` |
-
| rid | 角色 id
| 不能为空`参数body参数` |
-
-
- 响应参数
-
-
| 参数名 | 参数说明
| 备注 |
-
| ------- | --------
| ---- |
-
| id | 用户 ID
| |
-
| role_id | 角色 ID
| |
-
| mobile | 手机号
| |
-
| email | 邮箱
| |
-
-
- 响应数据
-
-
``
`json
-
{
-
"data": {
-
"id": 508,
-
"rid": "30",
-
"username": "asdf1",
-
"mobile": "123123",
-
"email": "adfsa@qq.com"
-
},
-
"meta": {
-
"msg": "设置角色成功",
-
"status": 200
-
}
-
}
-
`
``
3.1.4页面复杂度
1页面接口调用当前页面调用
2页面样式当前页面微调
3页面不封装组件
4页面不用vuex
3.1.5小结
很显然 第一次接触的后台管理系统他没有任何的一个难度 算是入门水平 这就是为什么很多人选择网上买课程的原因吧 这里没有vuex 没有组件封装 没有组件传值 没有过多的复杂操作
4.1进阶版后台管理系统（SBS+后台管理系统）
为什么说是进阶的系统呢 因为对其中的一些元素加入更多 有了组件封装 组件传值 vuex
4.1.1项目演示
毕竟开始商用了 所以呀 从代码的构造上就开始变得复杂了
4.1.2目录结构
代码开始趋向复杂化了 常规用到的vue的组件都开始引入了 vuex这边用的较少 但是引用到了 组件封装 多个组件可以重复拿过来用 就直接用了
4.1.3接口文档
这边就不展示接口文档了 多的可能就是有个工具生成了接口文档 需要postman进行一个本地测试了
4.1.4页面复杂度
1页面接口调用当前页面调用（页面接口调用可以父子调用）
2页面样式当前页面微调（开始有全局调用了）
3页面不封装组件（组件开始封装 耦合性更低）
4页面不用vuex（页面开始用vuex 但是用的极少 除了很需要的一些用户 部门才会存储起来 留存使用）
4.1.5小结
随着我们工作的不断学习 进入一家公司的历练 代码的写作需要更高的水平 而不是需要一个自学的水平
5.1继续进阶的系统（某大型公司的系统）
5.1.1项目演示
此处不便项目演示
5.1.2目录结构
5.1.3接口文档
Swagger工具获取 可以在线调试 直接mock数据 接口未开发就可以进行前端页面的全部开发
5.1.4页面复杂度
1页面接口调用当前页面调用（页面接口调用可以父子调用）
2页面样式当前页面微调（开始有全局调用了）
3页面不封装组件（组件开始封装 耦合性更低）
4页面不用vuex（vuex用的很多 所有的接口调用直接用过vuex去识别和规范）
5自定义指令 公用方法进行封装
5.1.5小结
一开始接触好的架构对你的成长还是有飞快的促进作用 所以选择平台的重要性就凸显出来了
6.1....更进阶的代码架构和规范
7总结
综上所述 搭建一个好的vue+element的项目
1抽离出公共方法（引用的时候直接import和export即可 提高代码复用性）
2发送请求的方法（常见的有ajax axios等都是可以选择的 本文第二个项目用的就是简单的一个接口封装 还是页面的一个调用 第三个直接在vuex里面实现了接口的全部）
3接口文档（接口文档 可以通过一个后台直接模拟数据 在接口还没有开发好的时候就可以进行一个前端开发）
4组件封装（对于经常用到的组件可以进行一个手动封装 便于后期维护）
5定义全局样式（设定整个页面的整体架构 保持页面的美观）
6定义自定义指令（自定义指令可以帮助我们进行代码的一个高度实现）
附录:代码规范
最近学到的一些规范 当然不全 持续总结
-
代码规范
-
1
变量
方法命名驼峰
变量命名需要有意义
-
2
两种情况判断多用三元
-
3element
设置宽度直接内联
-
4
按照云安全中心架构代码构造
-
5
公用组件注释少写
注释少写
-
6
页面不用的逻辑找到摈弃
-
7console.log及时清除
-
8
全部用三等
不可以二等
需要全等
-
9
尽量避免污染公共组件
代码注重优化
-
10
提示只留一个提示
提示不要加感叹号
我是歌谣 一个vue+elment的项目都是常规的一些项目流程 如何用最少最简单的代码实现才是我们的根本选择 不要为了实现功能写代码 实现功能的同时需要思考一下优化 简单 维护性高 规范 欢迎补充.....
推荐阅读
转载：https://blog.csdn.net/weixin_43392489/article/details/116800972