【實戰項目i護理下篇】vue-cli3+vue-admin+egg（業務邏輯）

上篇：【實戰項目i護理上篇】vue-cli3+vue-admin+egg

中篇：【實戰項目i護理中篇】vue-cli3+vue-admin+egg（部分源碼+效果圖）

預測：i護理可能會有下下篇。。。
我覺得用上中下來區分進度好像不太好吧。。。。
我的上一個項目【通告隨時知】的進度是按照時間節點來的
所以這一次倒是給自己挖坑了？？？
算了，不糾結，重點是記錄進度，對不

背景啥的在上篇，部分源碼的在中篇，這一篇主要來說一下一點功能和業務邏輯。

其實i護理的初衷是爲老人服務，而現在依舊是這個初衷。

只是一開始的時候，設計上感覺沒設計好。
所以現在開發就會遇到很多糾結的地方。

原本應該有權限控制，但是由於這個項目分爲子女/老人版本，醫生/護工版本
所以權限控制模塊就顯得沒有太大的必要去寫了。

既然是兩個版本，那麼應該是兩個運行系統，兩套界面。
但是我客戶端（也許有人會說移動端，或者是webApp端，反正通俗的說就是前端）寫在一個系統上了，就在開發過程中造成一些冗餘感。

開了兩個瀏覽器，所以界面看上去好像是分開了兩個版本了。但是代碼是在一個系統的，後期要是維護的話，可能會麻煩一點。

麻煩在哪裏？可以看看主頁的界面，訂單order裏面有childOrder
也就是子女的一些頁面和護工的一些頁面是在一個文件夾裏面的。。。
其實可以單獨建兩個文件夾來存放，但是現在已經有點晚了。。。

這一個週末的話，主要是寫了一個功能。
本來應該用服務推送來寫的，但是時間問題，短期內實現不了，所以就客戶端用一個定時器不斷請求後臺，雖然說他們實現的原理都是監聽，但是目前沒有第三方服務推送，就用定時器實現這樣的功能效果了。

作爲用戶（老人/子女）如果需要預約的話，流程是這樣

子女版本上

假設我們在預定護工界面點擊了確認預定

護工版本上

護工收到消息

她就可以去我的頁面查看剛剛用戶預定的訂單了

點擊訂單查看詳情

核心業務功能

共有的功能:

• 登錄
• 註冊
• 查看輪播圖廣告位
• 修改個人信息
• 退出登錄等

子女/老人版本:

• 預定護工(進行中)
• 在線諮詢(待完成)
• 關聯家屬(完成)
• 查看科普文章
• 收到服務通知功能(完成)

醫護版本:

• 發佈文章(完成)
• 收到服務通知功能(完成)
• 護工發佈服務(完成)
• 護工查看服務

組件樹

• 醫護版本
  
• 子女版本
  

說一說服務端

egg-sequelize就包含了egg-mysql的功能

sql熟練的話，直接egg-mysql搞起
不熟練的話，egg-sequelize更方便

egg-mysql的話，查數據就是

SELECT * FROM xxx where xxx=xxx

egg-sequelize的話，既可以像上面那樣，也可以

xxx.findAll({where:{xxx:xxx}})

我的數據庫放在阿里雲

項目小結

• 本項目的客戶端採取vue-cli3搭建，佈局使用mintUI+elementUI進行開發
  本系統有老人版本和子女版本。
• 後臺管理系統採用iview admin技術棧，分爲普通用戶（老人/子女）和醫護人員（醫生和護工），同時管理員也會對註冊成爲醫生或者護工的用戶進行審批。因爲醫生可以發佈科普文章，所以後臺管理員會審覈改科普文章是否通過，如果後期發現文章存在虛假信息，可以對該篇文章進行停用。
• 服務端主要使用了node（egg）—MVC模式來進行開發，通過進行各種需求分析，設計系統功能，使用Navicat工具設計出合理的數據庫。
• 系統在技術上使用前後端分離進行設計，對前後端分開設計可以增加系統的可維護能力

個人小結

1. i護理的初衷是爲老人服務，而現在依舊是這個初衷。
2. 只是一開始的時候，設計上感覺沒設計好。
   所以現在開發就會遇到很多糾結的地方。比如訂單模塊
3. 原本應該有權限控制，但是由於這個項目分爲子女/老人版本，醫生/護工版本
   所以權限控制模塊就顯得沒有太大的必要去寫了。
4. 既然是兩個版本，那麼應該是兩個運行系統，兩套界面。
   但是我客戶端（也許有人會說移動端，或者是webApp端，反正通俗的說就是前端）寫在一個系統上了，就在開發過程中造成一些冗餘感。
5. 開了兩個瀏覽器，所以界面看上去好像是分開了兩個版本了。但是代碼是在一個系統的，後期要是維護的話，可能會麻煩一點。