【实战项目i护理下篇】vue-cli3+vue-admin+egg（业务逻辑）

上篇：【实战项目i护理上篇】vue-cli3+vue-admin+egg

中篇：【实战项目i护理中篇】vue-cli3+vue-admin+egg（部分源码+效果图）

预测：i护理可能会有下下篇。。。

我觉得用上中下来区分进度好像不太好吧。。。。

我的上一个项目【通告随时知】的进度是按照时间节点来的

所以这一次倒是给自己挖坑了？？？

算了，不纠结，重点是记录进度，对不

背景啥的在上篇，部分源码的在中篇，这一篇主要来说一下一点功能和业务逻辑。

其实i护理的初衷是为老人服务，而现在依旧是这个初衷。

只是一开始的时候，设计上感觉没设计好。

所以现在开发就会遇到很多纠结的地方。

原本应该有权限控制，但是由于这个项目分为子女/老人版本，医生/护工版本

所以权限控制模块就显得没有太大的必要去写了。

既然是两个版本，那么应该是两个运行系统，两套界面。

但是我客户端（也许有人会说移动端，或者是webApp端，反正通俗的说就是前端）写在一个系统上了，就在开发过程中造成一些冗余感。

开了两个浏览器，所以界面看上去好像是分开了两个版本了。但是代码是在一个系统的，后期要是维护的话，可能会麻烦一点。

麻烦在哪里？可以看看主页的界面，订单order里面有childOrder

也就是子女的一些页面和护工的一些页面是在一个文件夹里面的。。。

其实可以单独建两个文件夹来存放，但是现在已经有点晚了。。。

这一个周末的话，主要是写了一个功能。

本来应该用服务推送来写的，但是时间问题，短期内实现不了，所以就客户端用一个定时器不断请求后台，虽然说他们实现的原理都是监听，但是目前没有第三方服务推送，就用定时器实现这样的功能效果了。

这周的话就补充写了一些静态页面

粗略截图两张（医院推荐和在线问诊）

目前的话是静态的，后期看看有没有机会去实现

接下来是订单的 订单的有交互的

就是老人/子女版本预定护工 护工会收到消息的

作为用户（老人/子女）如果需要预约的话，流程是这样

那个消息，我是在最下面那个导航栏加了请求代码，每次点击都会去请求后台的，那些小提示就是通过导航栏请求后台，然后存入localstorage全局公用的

本来打算用IM，但是那个短期内学习起来太耗时了

子女版本上

护工版本

核心业务功能（共有的功能）

登录

注册

查看轮播图广告位

修改个人信息

退出登录等

子女/老人版本:

预定护工(进行中)

在线咨询(待完成)

关联家属(完成)

查看科普文章

收到服务通知功能(完成)

医护版本:

发布文章(完成)

收到服务通知功能(完成)

护工发布服务(完成)

护工查看服务

组件树

• 医护版本

• 子女版本

项目小结

本项目的客户端采取vue-cli3搭建，布局使用mintUI+elementUI进行开发

本系统有老人版本和子女版本。

后台管理系统采用iview admin技术栈，分为普通用户（老人/子女）和医护人员（医生和护工），同时管理员也会对注册成为医生或者护工的用户进行审批。因为医生可以发布科普文章，所以后台管理员会审核改科普文章是否通过，如果后期发现文章存在虚假信息，可以对该篇文章进行停用。

服务端主要使用了node（egg）—MVC模式来进行开发，通过进行各种需求分析，设计系统功能，使用Navicat工具设计出合理的数据库。

系统在技术上使用前后端分离进行设计，对前后端分开设计可以增加系统的可维护能力

个人小结

i护理的初衷是为老人服务，而现在依旧是这个初衷。

只是一开始的时候，设计上感觉没设计好。

所以现在开发就会遇到很多纠结的地方。比如订单模块

原本应该有权限控制，但是由于这个项目分为子女/老人版本，医生/护工版本

所以权限控制模块就显得没有太大的必要去写了。

既然是两个版本，那么应该是两个运行系统，两套界面。

但是我客户端（也许有人会说移动端，或者是webApp端，反正通俗的说就是前端）写在一个系统上了，就在开发过程中造成一些冗余感。

开了两个浏览器，所以界面看上去好像是分开了两个版本了。但是代码是在一个系统的，后期要是维护的话，可能会麻烦一点。