OA办公自动化系统--业务逻辑梳理

前言

这篇文章不会涉及多少代码，重点是思路，基本都是伪代码。如果你是来找代码的，可以关闭网页了。

说明

虽然主要是后台的东西，但也应该注意区分前后台的业务。后台负责的主要是业务逻辑处理，前台主要是相应效果的展示。

目录结构

• 在动手做之前，先确定技术选型，是用ssm框架还是jsp+servlet

• 哪个熟悉用哪个，因人而异，我比较懒，用框架起步后就开始写了

• 确定技术选型后新建一个javaweb项目，对主要目录结构进行必要的层次划分

• 推荐的src文件目录划分如下：
  

• 基于动态代理，配合SSM使用，每个包什么意思，该放什么就不多说了

• webContent目录，如果你用了myeclipse就是WebRoot，问题不大
  

• admin/文件夹里放置后台界面

• jsp/文件夹里放置前台界面

• admin和jsp文件夹下除了放置jsp页面，还应有js，css，images,font, include文件夹

• font根据需求定，字体图标推荐阿里矢量图库

• include文件夹是抽离出的公共部分，比如公共头部，底部，侧边栏

• 注意，这里最底下的index.jsp是前台首页

• 说下可选的file文件夹，看个人需求，可以用来放会议纪要，日志，报表系列的东西

• 好了，至此，项目目录介绍完毕，业务部分正式开始

---

用户登陆

前台登陆

基础要求

核心需求就是登陆，但是登陆衍生出许多小的需求，如果你会且不懒，那该有的要注意到

• 先把界面做出来，可以丑一点，比如我的这个，一个背景图一个表单就好

---

衍生需求一：表单数据有效性校验

这个表单数据有效性校验主要体现在两个方面，一是非空校验，二是数据合法性校验，涉及到表单验证，那你没理由不用正则表达式，没理由不用ajax。如果你还不太懂正则表达式，请移步：https://blog.csdn.net/qq_42813491/article/details/87542552

数据的合法性校验

* 账号密码的长度限定，这个按照你的需求设定来
* 用户名是否存在的检验--ajax
* 用户名正确的前提下，密码是否输入正确

衍生需求二：体验感升华

一般而言，表单数据合法且成功提交就可以了，但是呢，通常会考虑下用户体验，当然，你也可以不考虑。。。

• 敲回车登陆–回车键监听，keyCode
• 切换密码框数据的显示与隐藏，改变intput 的type属性，password->text,text->password
• md5加密–比较加密后密码是否与数据库中加密的密码字段一致

衍生需求三：退出登陆

通常一个完备的系统都有这个业务需求，实现也很简单，干掉用户登陆时下发的session，重定向到登陆界面

核心业务：登陆

首先你应该先理解这个业务的本质是什么，没有多高深，无非是比较一下表单提交过来的数据和数据库中保存的数据是否一致。一致则登陆成功，反之，登陆失败，给出对应的提示信息，如：账号或密码错误。

具体分为三种情况，基于ajax

* 用户名不存在，直接返回，提示相应信息
* 用户名存在且正确输入，根据用户名去数据库查询密码字段，将查询结果与用户输入的密码做比较
* 一致，则登陆成功，下发session保存用户信息，跳转到首页。
* 反之，登陆失败，提示密码错误

• 补充一点，安全起见，除了登陆界面，都加访问控制，即未登录毛毛都干不了
• 至此，简单的登陆业务结束

后台登陆

登陆都是一个登陆，但你可以弄点新意，提升用户体验感
比如，实现这样一个小需求，正确输入用户名后，显示用户头像

基础要求

• 嗯，还是一个简单的登陆界面就好

• 我是一时兴起就把GitHub的登陆界面拿过来了，干净整洁

异步头像渲染

• 正确输入用户名后

接下来说一下怎末实现的，核心是ajax。首先，文本框失去焦点时，获取其value值并发送Ajax请求到一个action，这个action只做一件事，根据用户名查询数据库中存储头像路径的字段并响应回去。此时，在Ajax的回调函数里边就可以获取到这个路径，替换上边img标签的src属性值即可

个人信息

个人信息这里是前台界面的东西，需求就两个，查看和修改。但是在这之前，你应该设计好所有的UI界面，并且数据库设计了合理的字段。

数据字段

一般而言，职员个人信息包括但不限于职员编号，姓名，年龄，性别，手机号码，所属部门，所在小组，等级标识，登陆密码，职员状态。这里主要说一下等级标识和职员状态是干嘛的，公司除了普通职员，还会有小组组长，部门主管等职务，不同的等级标志用于区分不同的权限。比如，普通职员没有审批权限。此外，员工可能有出差，请假，倒休，在职，离职等诸多状态，职员状态字段就是用于区分这个的。

信息展示

• 本质就是一条sql语句的事，根据职员编号查询数据库，将查询结果渲染到界面上
• 也许你会疑惑，这个职员编号哪里来？登陆成功下发的session中

信息修改

• 本质也是一条sql语句的事，但不是一次搞定的。
• 先根据职员编号查询数据库，将查询结果渲染到指定的编辑界面上
• 注意，这个界面最初的数据渲染应该由表单的value值呈递
• 编辑完毕再次通过表单提交
• 成功提交后，后台处理完毕再次跳转到当前页面，或者跳转到前台首页可以
• 这个时候是转发还是重定向都可以，数据库已经被更改，不涉及作用域值的问题

组织架构

需求描述

同样的，这个也是前台界面，需求只有一个，层次树的形式展示组织架构。
最顶层是公司名称，其次是下属的所有部门，部门下再设小组
点击某个小组，可查询到这个 小组所有的职员
再点击某个职员姓名，可以查看该职员的详细个人信息，包括不限于在职状态，姓名，年龄。。。

实现逻辑

好好想一下，其实这个需求并不难，只是一次又一次的查询而已，先捋一下逻辑

• 首先，进入组织架构这个页面的时候，就发送一个请求到指定的action，将公司所有部门查询出来
• 点击某个部门，再去查询它的下属小组。也可以简单点，每个部门都是ABCD四个小组，然后点击哪个部门就显示对应的分组。
• 比如这样：只有点击的时候会展示，不点不显示，再次点击会折叠
  
• 当点击某个小组的时候，会查询到这组下的所有职员，其实也很简单，每个职员身上有个所属小组的字段，根据这个查就行了
• 至于这个小组怎末确定，点击哪个就传哪个
• 最后一步就是根据职员姓名查询全部信息，道理一样的

权限

权限管理因人而异，亦可以不单独拿出来，这里只考虑单独拿出来的情况。权限管理属于后台界面，由人事部主管或者超级管理员进行相应职权分配。不同的职权对应职员的等级标识，所谓的权限分配也没有那么高大上，本质就是修改职员身上的等级标识字段。

查看

• 列出所有职员信息，不用查询全部字段，简单写几个就好，包括不限于职员编号，姓名，职员等级，所属小组，所属部门

分配

实现权限分配也是一步的事，执行sql的修改语句，根据职员编号，修改职员等级

• 在设计层面，可以将职员等级设计成一个下拉框或者数字框，我这里用的数字框

• 这里要考虑下事件触发的时机，监听数字框的change事件，将更改后的数据传递到指定的action，处理完毕后跳转到当前页，再次查看，数据已经发生改变。对应的，职员的等级也就发生改变了。

权限的体现

• 单独设置是没什么用的，必须有回应。怎末回应？举个简单的例子，后台登陆，除了校验用户名密码，还要判断职员等级标志是否达到最高权限，若没有，提示权限不够。当然，我比较懒，权限这部分业务写的都是单向的。。。

考勤

在考勤这部分，同样的是分为前后台，前台打卡，将数据成功保存到数据库，后台将查询结果渲染到界面上，这部分做的也不是很细致，说下思路，不难。

需求分析

• 前台而言，两个需求
• 第一，地图大致范围显示，完成打卡。
• 第二，查看个人考勤数据报表，可导出。

业务实现

先说地图的事，采用第三方地图API，比如百度地图，以js为例：http://lbsyun.baidu.com/index.php?title=jspopular3.0，里边有很多demo，找个合适的用就好了
至于报表的导出，H5有个新api可以将table标签的东西转成excel表格导出，详情参见：https://blog.csdn.net/qq_42813491/article/details/89253326

** 对于后台，除了查看考勤数据外，还可以修改职员的考勤状态等字段**

• 一条sql的事，不细说了

部门管理

增加

• 本质就是一条插入的sql语句

删除

• 本质就是一条根据部门编号删除数据的sql语句

编辑

• 本质就是一条更新的sql语句
• 先查后改

查看

• 本质就是一条查询的sql语句

职员管理

• 同上
• 模糊查询，没啥劲，只是在查询的时候加个where语句而已

公告管理

• 同上

• 相比于其他，公告管理还有个小需求

• 点击公告标题，显示详细内容

• 前后台都有这个需求，不同的是，后台增删改查都可以，前台只能看

  这个业务实现更简单

  • 首先，公告字段包括但不限于id，标题，内容
  • 本质就是根据id或根据标题查询内容，将数据渲染到指定位置即可

日志管理

其实这些东西都是重复的业务，但可以用权限区分使得相同的同时有些不同
具体实现就是每个人都可以写会议纪要，但是只有普通职员写日报，只有小组组长写周报，只有部门主管写月报
登陆的时候判断职员等级，不同等级在日志这一栏显示的书写内容不同

日报

周报

月报

会议纪要

• 本质都是增删改查，除此之外，没什么新意

审批

实际上，下边这一堆审批也是相同的业务，单独写其实没什莫意义。事务审批的时候，可以设置一个类型字段

加班申请

倒休申请

请假申请

出差申请

入职申请

转正申请

外出申请

调岗申请

离职申请

我审批的

我发起的

• 我审批的和我发起的不是哪个职员都有的，根据权限而定
• 数量统计参考数据库的count