記得阿朱在《走出軟件做坊》一書中有一章講客戶提的需求太邪門了,鼠標鍵盤不太會用要程序員開發一個語音輸入功能,還要系統中帶相似QQ的功能;確實剛開始的客戶的想法有點天真,可是隨着信息化的愈來愈廣泛,客戶對信息系統也比較瞭解,特別年輕的信息管理人員,除了接受能力強,而且長期站在客戶的角度對信息系統也有一些獨特的看法,跳出技術框框外的想法;程序員
其中有個年輕的信息人員聊天的時候說了一些對系統的要求,其中有一個功能是這樣的,部門人員向庫房申請一批物資,之前的作法就是先把申請單內容錄入系統,而後再電話通知庫房人員叫他們審覈申請單,審覈完後覈對沒有問題,庫房人員再打電話通知他們何時送貨過來;如今聽了他的意見改進後,部門人員錄完申請單,保存的時候系統自動發送一條消息給全部庫房人員,庫房人員的電腦會彈出一個相似QQ的通知框,庫房人員就會立刻審覈此申請單,而後審覈完成後,系統又會自定生成一條消息發給接收部門;全程不再須要電話聯繫,系統給人帶來一種比較智能的感受;數據庫
固然他跟我講得並不止這一點點,如申請也不該該由他們本身錄入,應該是系統自動給他們生成,還有系統不少環節不該該是由人做爲事件的開始點,應該由系統主動的作出判斷並提醒操做人員應該作什麼,還有哪些事須要作;我最後的感受就是之前的系統只是一個單純的工具,操做人何時要用就拿過來用一下;而之後的系統應該更智能,從被動的接收變爲主動的提供工做上的指導,實時促進崗位上人員的工做;從被動的信息傳遞到主動的信息分析;框架
又跑遠了,本章內容是講框架中的「消息管理」模塊,固然此功能確定沒有上面說的那麼神,其實就是一個簡單的短消息功能,與業務系統的緊密集成,實現業務出現多崗位的時候可以實時的發送消息給對應的人員;把消息類型的管理與消息的推送封裝成一個公共的模塊;而消息什麼生成與生成什麼內容就須要深刻的分析業務創建相關模型了;工具
本文要點:spa
1)功能清單介紹3d
2)功能界面展現blog
3)核心業務流程圖與數據庫表關係圖接口
4)關鍵點的技術實現代碼事件
模塊名稱開發 |
功能名稱 |
功能說明 |
系統消息 |
消息類型設置 |
消息類型維護,新增、修改、停用 |
消息記錄管理 |
查看消息,未讀、已讀、已發 |
|
消息實時提醒 |
產生新的消息,推送給用戶,主界面給出提示框 |
1.消息的兩種模式
看上面兩張業務流程圖,模式一消息類型定義好用戶角色,模式二用戶自定義訂閱本身的消息;模式一適合崗位很是固定的企業,消息推送按照配置好的角色就好了;模式二適合一人多崗,崗位人員比較靈活的那種,由於崗位靈活若是按照模式一的方式,那此人可能時時刻刻都會受到消息的騷擾,應該上午作這個事,那麼就應該只推送這個事的消息就好了,下午就推送下午的消息;因此須要用戶本身維護本身的消息接收時間和內容;
2.產生消息的統一接口