基于状态检修的试验数据分析系统--开发日志（三）--框架选型

框架选型

开发者最为头疼的问题无非是前端代码调试、RBAC权限管理。为了节约时间，经过多次筛选，最终选定tpadmin v1.2。
tpadmin v1.2看云文档

tpadmin v1.2框架特征

tpAdmin 是一个基于 ThinkPHP5.0 正式版和 Hui.admin v2.5 的管理后台，简化管理后台的开发流程，简化代码的编写，提高代码复用率，同时集成完整的权限管理和其他管理后台中常用的功能

tpAdmin 是一个通用管理后台，不涉及任何死板的前端框架，或许它没有像 easyUI 这样的框架那么强大，却给了你非常灵活的开发模式，允许你加入任何你喜欢的插件、前端组件到框架中去，开发前也不需要看大量篇幅的前端文档。

因为它非常灵活，所以你可以利用它开发任何 B/S 架构的管理后台

后端

模板、控制器、模型、验证器、数据表自动生成
RBAC 权限管理
完美支持多级控制器及多级控制器权限管理
支持前置方法 before
支持方法拦截器，实现请求拦截
支持过滤器
支持模板主题（需自己按照文档修改官方源码使用）
节点自动扫描与添加
七牛上传及与百度编辑器 (Ueditor) 结合使用
Excel 一键导出和一键导入
邮件发送( Fsock 和 phpMailer 两种驱动)
ID 加密解密
网站操作日志记录（自动水平分表）
图片上传管理及回调

前端

表单校验
无限层级菜单，完美与后端多级控制器兼容
自动面包屑导航
基于 layer 的丰富弹层
支持 H5 + iframe 自动切换的无刷新上传
ajax 请求处理封装，直接后台返回数据控制前端页面处理
多窗口办公
随机字符串生成
表格溢出处理
图片预览
二维码生成

本平台使用了如下框架或插件、源码：

ThinkPHP 5.0.2 正式版
Hui.admin v2.5
layer
jQuery Validform
七牛
...

tpadmin v1.2框架节点拓展

对于开发者来讲，回忆开发过程、调试BUG是件麻烦的事情。仅在此切图记录，不做无谓的浪费。

tpadmin v1.2目录结构

面向对象的开发，与以往的开发模式思路不同，因为是拿来主义，直接利用成型框架集进行快速开发，开发之前首先要读懂文档，了解开发团队的开发思想，继而加以利用和改进。

开发之前，首先要了解开发思想和目录结构。目录结构是利用控制器实现开发思想的一个过程。或许读取该目录结构，厘清控制器的运作、路由规则，对于开发者来说非常困难，也有不少从小白学期的开发者，时时想要放弃。熬过这段痛苦期，将会找到许许多多的乐趣。

下面是 admin 模块的目录结构，tpadmin 只涉及 admin 模块和项目配置文件 config.php

admin 模块
├── common.php 应用公共（函数）文件
├── config.php 应用（公共）配置文件
├── database.php 数据库配置
├── tags.php 行为配置
├── Controller.php 公共控制器
├── extra 扩展配置文件
│ ├── captcha.php 验证码配置信息
│ ├── conf.php 其他配置信息
│ ├── hashids.php ID 加密配置信息
│ ├── mail.php 邮件发送配置信息
│ ├── qiniu.php 七牛上传配置信息
│ ├── rbac.php RBAC 权限管理配置信息
│ ├── site.php 网址站点信息配置信息
│ └── weblog.php 操作日志配置信息
├── behavior
│ └── WebLog.php 网址操作日志行为
├── controller 控制器文件夹
│ ├── Generate.php 代码自动生成控制器
│ ├── Index.php 管理后台首页控制器
│ ├── Pub.php 公共无权限管理控制器（登录、密码修改、个人信息修改）
│ ├── Ueditor.php 百度编辑器 Ueditor 集成七牛上传服务地址
│ ├── Upload.php 文件上传控制器
│ └── …
├── logic 逻辑模型文件夹
│ ├── …
├── model 模型文件夹
│ ├── …
├── taglib 自定义标签扩展文件夹
│ └── Tp.php 自定义标签，包含权限控制器标签和 widget 标签
├── traits traits 多继承文件夹
│ └── controller
│ └── Controller.php 公共控制器多继承 traits ，公共方法全部放在此处，如需使用请自行引入
├── validate 验证器文件夹
│ ├── …
├── view 视图文件夹
│ ├── generate 代码自动生成视图文件夹
│ │ ├── index.html 代码自动生成首页文件
│ │ └── template 代码自动生成模板文件夹
│ │ ├── Controller.tpl 代码自动生成控制器模板
│ │ ├── edit.tpl 代码自动生成添加、编辑页模板
│ │ ├── Model.tpl 代码自动生成模型模板
│ │ └── Validate.tpl 代码自动生成验证器模板
│ ├── index 管理后台首页视图文件夹
│ │ ├── index.html 管理后台首页模板文件
│ │ └── welcome.html 管理后台首页欢迎页模板文件
│ ├── template 管理后台公共模板文件夹
│ │ ├── base.html 视图基础模板
│ │ ├── edit.html 添加、编辑页示例模板（不能直接继承使用，仅供参考，其他模板都是继承或引入使用）
│ │ ├── index.html 视图首页模板
│ │ ├── nav_left.html 管理后台首页左边鼠标悬浮菜单模板
│ │ ├── nav_menu.html 管理后台首页左边权限导航菜单模板
│ │ ├── recyclebin.html 视图回收站模板
│ │ ├── recyclebin_menu.html 视图回收站菜单模板
│ │ └── table_menu.html 视图首页菜单模板
│ ├── …
└── widget widget 小组件文件夹
└── Index.php 管理后台首页小组件控制器

选型意味着整个项目的框架也要有预见性！！

这已经是第二个版本的系统开发，1.0版仅把基础录入部分和计算部分容纳进去试验通过，正确率100%，由于各种原因放弃开发，保留框架。

第二个版本除了MVC模式下的RBAC，新增的有节点、EXCEL一键导入。其余插件，后期开发后期再拓展。至于python的大数据分析、OCR图像识别技术、视觉图表技术、数据库内搜索算法、冒泡算法、比对算法、差值算法、DOC文档的导入导出，或者提高录入的方式，后期我想还会有许许多多耗费精力的插件产生。

尤其是数据分析，还要考虑到，要不要引入语义分析？如果单纯是导入，那样会简单的多；如果涉及到OCR识别再转入文档再语义分析，那样可能会拉大框架与人工智能无异，有点得不偿失。

所以无论是小白还是后来开发者，对于MVC架构的思考和理解，占据调研工作的大部分时间。对于架构的思考，也必须要有前瞻思维，否则到项目后期再去修改架构，容易推倒重建造成成本浪费，重新修订路线可能牵一发而动全身。

数据源哪里来？

前天、昨天、去年、前年，尤其是近几日，同行间对这些问题做出了讨论。

其实吧，我们要开动一个项目，促使一个项目成功开发，总要遇到这样或那样难以调和的问题。例如厂家设备的数据联动、是否为了完成政治任务而跟风做起的项目、设备数据是否真正能帮助指导生产？我觉得从简单入手，从细微处切入即可，毕竟都还没有成长为资本雄厚的开发型公司。

关于数据源，前文已有交代。这里要说明几点：

1、电是特殊商品，围绕这一特殊商品的领域不计其数。电力行业细分化领域许许多多，工种也不计其数（最起码我统计不完）。有些老职工一辈子可能没有见过那么多先进的思维、先进的设计和先进的技术，大部分还是愿意接受成熟的技术，因为试错的成本很大有可能是不可逆的（比如说带电测试）。笔者能够亲身听到、看到、参与到，幸运无比。

2、电力设备相对昂贵。只要是跟电力有关的，主业产品必定比市场流通产品价格昂贵。这就不单单是成本问题了。有管控、有质检、有试验、有技术支持，推广、维护、追责…

3、责任划分界限。输变电系统是一个双向型、多元、复杂的系统。有可能是发电厂的，有可能是输配电的，也有可能是用户的。输变电是我们的主业，一般是以令克以下为界限。但是有好多属于配网的用户电气设备问题，业主可能会推脱责任给电力公司。典型案例譬如关虎屯事件，感觉力不从心在此不胜枚举。

4、业务权限。为了简单切入，我们只选取了电力变压器作为数值分析的主要目标，据此拓展。因为在电网当中，这个造价不菲的大部件属于心脏，围绕心脏联动的设备许许多多。因而也不会牵涉到厂家的数据、在线监测的数据、配网设备的数据。那些数据没有协调部门也拿不到，煞费苦心。并且，根据国标扣标准，一直是行业内部通用做法。