所有系统的开发都受限于当时的技术积累、人力资源、设计方案,没有完美的系统,
我们只是在自己的技术能力内做到100分。 -- fuyuan
没有完美的系统,只有适合的系统。我不是大神,本文结合我以前在一个企业的CRM管理系统和后来开发维护的一个系统来说介绍下我踩过的坑。
业务背景
先说下业务背景吧,我当时接手重构改造任务的时候,面临如下情况:
- 老系统部署环境比较陈旧,还是apache+php, 比较老的环境了,经过若干年人员更替,部门分拆,已经不能说清楚上面运行的各种服务了,运维部署起来也比较困难,哪天死了,基本上无法复制,单点情况比较严重。
- 所用框架也比较老旧,自有框架,不仅包含后台服务代码,还包含管理系统代码,开发维护也比较困难。
- 界面风格也比较旧,还是十几年前的风格,操作起来比较怪异。
- 领导授权说重构吧。这个是最关键的,领导授权,是一个项目启动的旗帜。
系统从开发到后来的优化都是遵循的原则PDCA。
好,汇总各方面需求总结的情况如下:
- 新作一个管理后台系统,最好与主业务一样的结构,这样便于开发。即linux + nginx + php + yaf + memcache + yaconf + mysql等等。
- 迁移旧系统功能,按时完成,实现新的需要的功能。
- 找个流行的响应式模版。
- 技术栈升级,这个是最近才加入的内容。
系统整体架构设计
开始的时候因为对yaf不太熟,所以没有注意到application.dispatcher.defaultRoute.controllerPrefer=true 这个配置。以至于 每次一个接口,都得重建一个文件,写一个controller。
后来我想了一方法:对于a/b/c_d 这种路由,自己写了个规则,映射到A_B_C controller的d action方法中。
这样 对于简单的增删改查方法,就可以放在一个文件里了。
model设计
访问数据库的model,因为yaf框架比较简单,所以我参照了thinkphp的访问数据库部分自己写了一个简单的模块。
后来一个兄弟引入了laravel的ORM模块Eloquent,不过没有迁移所有的业务,所以存在了两套内容。
账号
这个比较简单,跟常用的系统相同。
角色
角色管理是确定角色具备哪些权限的一个过程,他是一个集合的概念,是众多最小权限颗粒的组成。我们通过把权限给这个角色,再把角色给账号,从而实现账号的权限,这是网上摘抄的,我在系统中并没有实现这么复杂。没用用到 超级管理员,管理员,普通用户角色区分,这个要看系统应用场景吧。
权限的定义
网上有各种个样的帖子介绍管理系统的,我也介绍下我的这个系统里面权限的部分。
权限可以分为三种:页面权限,操作权限,数据权限
页面权限:即入口,用户可以看到哪个页面,看不到哪个页面。
操作权限:进入同样的页面,有些人看到这个按钮可点击,有些人只能浏览这个页面的数据。
数据权限:则是控制你可以看到哪些数据,比如会员的人A只能看到或者修改A部创建的数据,他看不到或者不能修改B部的数据。
我这边实现是限定一个一个常量列表和一个权限菜单。可以是增删改查的,我这边考虑到这个变化有限,所以只在代码中写成了固定的内容,增加一项菜单就改回代码就行了。
// 常量定义
define('P_USER_MANAGE', 1); // 后台用户管理
define('P_USER', 2); // 用户管理列表
define('P_GROUP', 3); // 组管理列表
... ...
// 权限树
P_USER_MANAGE => [
'title' => '后台管理',
'link' => '',
'class' => 'fa fa-user',
'child' => [
P_USER => [
'title' => '用户列表',
'link' => '/user/list',
'class' => '',
'child' => array()
],
P_GROUP => [
'title' => '组列表',
'link' => '/group/list',
'class' => '',
'child' => array()
]
]
]
这样 每次用户进入页面 再根据一定的算法获得用户 应该有的权限,相关代码可以参考:
https://github.com/netbird/permission
这个是以前实现的一个类,是将权限由低到高排列,保存的时候每4位转变成1个十六进制的字符,然后合并。
例如: 用户权限是 '', 把权限 12加上,就是1000 0000 0000, 保存就是,800。
主要实现了以下方法:
Permission::setuserPermission($permission_index, $user_perm)
// 这个是设置权限,比如用户的现在权限是'', 如果把12这个权限号码加上则执行:
// $user_permission = Permission::setuserPermission(12, $user_permission)
Permission::deleteUserPermission($permission_index, $user_perm)
// 删除权限
Permission::isAllowUserPermission($permission_index, $user_perm)
// 判断用户是否有权限
至于按钮权限,这个也可以参照这个进行,定义一个按钮的设置常量,判断有那个权限,则展示按钮。
数据访问,这个具体场景 具体分析了,不过每个接口入口的地方 至少需要判定访问权限。
响应式模版
技术讲究厚积薄发,只有平时多积累多实践,关键的时候才能发挥用途。因为以前做了类似的系统,所以利用了以下一个模版框架。然后进行改造。
我不愿意每次都写表格页面,所以使用jquery table这个第三方的插件,采用异步加载数据的方式。在这个插件上面进行了简单的二次开发。后来的大多数功能都是采用的这个插件。
bootstrap是个好东西,以前用的少,这次大规模使用,每天就是调页面,调前端。在笔记本上看着不错,到了显示器上就走样,很苦恼。不过我经手的页面普遍没啥问题。
功能改进
之前每次新建功能都得新建个表,然后写编辑页面,好烦啊。能不能搞个公用的机制,简单的引用就生成个简单的编辑页面。于是,我对编辑部分进行了封装改进。
先说下数据库:建造个公共表:主要包含 main_key, second_key, config_value,等内容,config_value是参照key-value格式数据库的value字段使用,当然 text类型最高65535个字节把,如果太大,会造成bug。
就是将关系型数据库作为key-value用了,一些加单的配置信息,经过json转成字符串然后保存下来。
自定义通用配置
有没有一种方案,能够不编写代码,仅靠后台点点就能满足配置? 于是先出设计方案,后加工。
一般的项目配置分成单页和列表的配置。可参照如下需求:
- 进入设置页面,创建1个item,类型分成单页和列表。
- 选择 编辑页面是否包含日期,发布权限的人员,可修改字段的人员,发布的文件名称等等吧。
- 单页面或者列表的单页面编辑页支持自定义字段编辑(可添加或减少字段)。
于是这个项目就产生了。虽然体验差了一点,但是基本满足需求,节约开发时间还是没有问题的。
模版
关于模版是在列表页面提出的,在自定义列表页,每次创建单页面的时候都需要重建数据很麻烦。于是改进了下,在配置页面有个模版设置页面,模版页面可以添加删除定义字段。这样在创建新页面的时候就可以继承模版了。
ini配置文件
关于生成的配置信息,我们还是采用了yaconf的php扩展插件,所以大部分配置以ini文件的形式推到线上。yaconf的用户可以参考线上说明。下面博客也总结了一些yaconf使用的坑。
一些使用Yaconf的经验分享
日志及备份
一开始记录mysql,每条都记录,后来发现不太好,需要的时候什么也查不出来。还是应该从产品的角度看这个日志吧。
这个模块一直在开发改进中。大致的方向是给使用者一个友好的查询界面,去查询相关的内容。
因为一些隐患,后来我加入了配置信息备份功能,每次配置更新的时候保存已有的线上这个文件配置,并且记录到数据库。然后做个后台,可以查看,比对配置并且上线。
这个地方引用了一个公共类库:https://github.com/chrisboulton/php-diff
vue
一次偶然的机会接触到vue基础知识,在系统的某些页面决定尝试以下,没有深入使用,只是引入了 vue.js。进行了一些页面处理,感觉确实方便了很多。当时只是看了vue的一些基础知识,有很多问题还停留在表面层,所以没有深入应用。
类似下面的代码,很舒服的感觉。
new Vue({
el: '#app',
data: {
source_url:"",
count_result_text: "",
uid: ""
},
methods: {
count_result: function () {
var that = this;
if (this.source_url == '') {
bootbox.alert('url不能为空');
return;
}
var param = {
"source_url": this.source_url,
"uid": this.uid
};
$.post('/api/counts', param, function(return_data){
that.count_result_text = return_data.s;
}, 'json');
}
}
});
Vue.js 组件与路由
ant design
年初,想对系统升级改造。增加几个模块,朋友推荐ant design。感觉挺好,使用各种入坑。
下面是一些问题的总结, 我在另外的两篇文章中提到的:
ant design form表单的时间处理
碰到一个ant design跨域问题
全新的开发模式,我很喜欢。
技术栈:react,ant-design,dva,Mock
关于dva,有个图,我想大家应该学习下:
本次学会使用了npm,webpack, mock.js, node.js等相关内容。
最后学以致用,技术永远为业务服务。这个是历史以来的道理。多运用,多思考。
转载于:https://blog.51cto.com/9681602/2300861