技術服務于業務，良好的技術設計和實作能夠大幅提升業務質量和效率，
PowerDotNet已經形成了自己的開發風格，很多專案已被應用于生產環境，可行性可用性可靠性都得到了生產環境驗證，
編程是非常講究動手實踐的科目，我們發明的框架、工具和方法論，如果自己都沒有做出有說服力的產品，沒有得到充分驗證，如何說服別人使用呢？
眼看千遍，嘴說萬遍，不如親自動手實作一遍，
從本文開始，將會介紹幾種像第一篇基礎資料平臺一樣，個人開發過的公共服務中更偏重于業務的公共服務系統，沒錯，某些業務系統也能成為全域通用的公共服務，
從第2篇到第11篇，更加偏重于公共框架服務、中間件和通用模塊，而不是具體業務，這個都是開發業務邏輯程式的前期準備程序，是為了更快更好可擴展可伸縮可運維兼顧靈活性的開發業務系統，
PowerDotNet設計與實作的一個重要目標就是，對于通用和常用模塊或功能，解耦并復用，減少重復建設，動動滑鼠搞定一切腳手架型的框架搭建，
有了前面那些文章的鋪墊，對于業務系統使用公共框架、中間件或服務，基本就是動動滑鼠的事情，
我個人接觸的廣義的CRM，通常包括HCRM（人員或員工管理）、PCRM（個人用戶管理）和ECRM（企業用戶管理），
本文只介紹HCRM人員管理平臺（側重于通用權限管理）這一部分，人員管理平臺相對基礎資料平臺業務邏輯更復雜一點，對于PowerDotNet而言只能算是小試牛刀，后續有空再介紹PCRM和ECRM，
我們在開發應用的時候，總需要和不同的人員打交道，比如一線業務、二線支持人員等，根據經驗，為他們開發合適的業務系統也是很有挑戰的事情，尤其是某些業務（如拉取訂單、辦公打卡等）某些時間段業務高峰期，設計實作沒處理好，很容易遇到性能瓶頸，
經過系統分析抽象和設計，我們發展出了HCRM系統，主要用于人員管理，
在前面介紹PowerDotNet的多篇文章中，我們總是能看到不同系統的管理后臺，每個管理后臺的選單幾乎都不一樣，這些管理后臺通用權限的開發，都離不開HCRM的設計與實作，
本文舉幾個常見功能，說說HCRM的平臺建設，
環境準備
1、（必須）.Net Framework4.5+
2、（必須）關系型資料庫MySQL或SqlServer或PostgreSQL或MariaDB四選一
3、（必須）PowerDotNet資料庫管理平臺，主要使用DBKey功能
4、（必須）PowerDotNet配置中心Power.ConfigCenter
5、（必須）PowerDotNet注冊中心Power.RegistryCenter
6、（必須）PowerDotNet快取平臺Power.Cache
7、（必須）PowerDotNet訊息平臺Power.Message
8、（必須）PowerDotNet檔案平臺Power.File（主要包括自定義頭像上傳、業務單據檔案或附件上傳等）
9、（必須）PowerDotNet基礎資料平臺Power.BaseData
一、人員權限
根據經驗，權限大概可以抽象為如下三個分類
1、功能權限
功能權限是我們日常生活中最常見最直觀理解的一種權限類別，主要解決能做什么的問題，如增加人員、修改資料等，
根據基于角色的權限控制（RBAC），設計實作人員功能權限管理，
有了用戶，就需要關聯用戶角色（也可以通過用戶分組對多個用戶進行角色關聯，用戶分組下面介紹）
按照用戶分組批量分配角色的情況也很常用，可以節省大量配置時間
再通過角色關聯權限，就可以間接得到用戶和權限的關系 （角色之間的權限則可以通過頁面工具進行批量復制處理）
上面的示例，基本上是最基礎簡單高效的用戶-角色-權限設計，事實上還可以對角色和權限再進行分組抽象，不過大多數業務沒有必要，最基礎的RBAC就是最強大的武器，
設計權限時，可以權限到選單，也可以權限到按鈕，權限是一種層級關系：
PowerDotNet在設計實作權限和選單的時候，參考了很多現有設計，很多現成的方案都是選單資源直接拿來當做權限使用，PowerDotNet則摒棄了這一做法，設計出了更加通用強大的自定義選單系統，
一個重要原則是，選單主要負責顯示，有樣式，有鏈接，有表現行為，而權限是靜態資料，需要和選單進行匹配關聯才能起作用，權限不等于選單，從而最大限度的復用權限和選單功能，
實作權限控制到BS頁面或者按鈕也很簡單，充分利用過濾器特性ActionFilterAttribute就行，提示也非常友好，參考下圖：
CS結構的則更加簡單，通過一個字典方法即可搞定，
2、資料權限
資料權限主要是為了解決能看到哪些（范圍）資料的問題，常見的業務場景比如：公司業務部門領導能查看所有下級的業務資料，普通人員只能查看本人的業務單據，
資料權限是對功能權限在縱向的擴展，
3、欄位權限
欄位權限主要是為了解決能看到哪些（欄位）資訊的問題，常見的業務場景比如：可以禁止指定用戶或角色對某些敏感欄位（如賬戶金額、短信內容等）的訪問，
欄位權限是對功能權限在橫向的擴展，
PowerDotNet目前完美支持資料權限和欄位權限控制，PowerDotNet把資料權限和欄位權限直接抽象為帶有DBKey和SQL陳述句的功能權限，
資料和欄位權限控制主要通過抽象出如下幾個和SQL查詢有關的欄位：
SelectSQL：SQL陳述句的SELECT部分，支持SELECT *或SELECT 具體欄位
TableName：SQL陳述句的FROM部分，支持資料表、臨時表、視圖、子查詢等
WhereSQL：SQL陳述句的WHERE部分，支持占位符（通過{引數名}的形式），支持引數化@符號，只要構造好查詢條件物件，框架自動構造并決議引數
OrderBySQL：SQL陳述句的ORDER BY部分，對查詢資料結果排序
GroupBySQL：SQL陳述句的GROUP BY部分
HavingSQL：SQL陳述句的HAVING部分
PagerSQL：SQL陳述句的分頁部分，分頁通常由ORM搞定，這里基本用不到，目前支持{CurrentPage}和{RecordCount}兩個動態條件
QuerySQL：完整SQL陳述句，支持引數化，如果查詢結構簡單，可以直接寫完整SQL陳述句，不需要動態拼接
PowerDotNet的資料庫ORM框架提供通用泛型GetPreparedSQL<T>(DataPurview permission, T qo)方法，內部動態拼接資料權限SQL陳述句，引數通過泛型方法GetDynamicParams<T>(string sql, T qo)反射構造完成，
通過上述兩個框架方法，可以控制任意的資料權限和欄位權限，絕大多數場景下的查詢問題都可迎刃而解，
相比一些其他的資料和欄位權限解決方案，PowerDotNet的權限控制不需要構造復雜的條件運算式和資料匹配關系，SQL完全由權限開發者掌握，配合DBKey萬能SQL查詢介面自動完成資料和欄位權限功能，
二、人員分組
人員分組是為了滿足可擴展性、可伸縮性以及靈活性而特意設計的，
組織機構的設計天生就是用來對人員進行分組的，
對于一般公司而言，基本的組織機構就是公司部門，每次新增一個員工，自動就會進入公司部門分組，
但是常見的公司部門組織機構還遠遠不夠，現實的人員分組情況遠遠比一般的公司部門型的組織結構更復雜，
前面我們提到，“可以對角色和權限再進行分組抽象”，HCRM經過權衡后沒有對角色和權限做出這種復雜設計，
但是人員關系必須要分組才能更好解決問題，
為了更好地管理人員，對人員進行分組歸類，PowerDotNet繼續抽象，設計出HCRM通用的人員分組，
人員分組之間也有關系，常見的關系結構包括：
1、一維結構：人員分組之間是平等的，沒有包含與被包含之分，
2、樹形結構：每個人員分組可以有一個或零個父級人員分組，
3、多父結構：每個人員分組可以有多個或一個或零個父級人員分組，但不能形成回圈依賴，
HCRM的人員分組原來設計是有經典的樹狀結構的上下級關系的，但是根據實際使用經驗，樹狀層級關系在人員分組里基本屬于過度設計，所以最新版本已經去掉了這個功能，
使用HCRM的人員分組功能，必須遵循一定的規范，
一個分組可以有多個用戶，一個人員可以加入多個分組，
對于常見的人員層級關系，比如公司部門有部門領導，倉庫有倉庫負責人，門店有店長......這種人員層級關系也能通過人員分組的一維結構設計來解決，
人員分組支持設定直接領導，查詢時稍加轉換，自動支持了人員層級關系，
人員分組管理主要涉及三張表，即人員和分組關系表（emp_refer_group）、人員分組表（emp_group）、分組資料源表（group_data_source），
分組資料源表（group_data_source）比較特殊，設計它主要是為了拿到對接的業務組織機構ID和名稱（biz_dept_id，如公司部門Id、倉庫Id、轉運中心Id、前置倉Id、配送站點Id等等），因為PowerDotNet的服務治理框架和資料同步平臺的存在，這個表通常情況下幾乎可以不用，
因為人員分組表（emp_group）設計的好，emp_group的biz_data_source欄位支持text、xml、json、或者直接服務名稱、資料表名稱，絕大多數的資料源場景都覆寫到了，非常有利于動態擴展，
通常對接業務方通過服務治理平臺注冊下資料源介面就可以了，也可以通過資料同步平臺同步業務資料至HCRM分組資料源表（group_data_source），這兩種模式非常有利于擴展各種資料源，
PowerDotNet建議直接通過服務治理平臺，按照約定好的資料源契約，業務方提供資料源介面，HCRM不寫一行代碼就在配置中心配置下服務介面名稱，服務治理框架自動搞定一切，對于各種新業務或者擴展業務做到完美兼容支持，
PowerDotNet的HCRM系統目前默認完美支持的組織機構型別包括公司部門、倉庫、配送中心、配送站點、自提點、網點、轉運中心、物體門店（如酒店等）、前置倉、供應商等，只要在管理后臺點點按鈕就可以支持更多這種可擴展的人員分組關系，
人員分組型別也支持動態“無限”靈活配置，
目前為止，HCRM這一套人員分組設計都運行良好，
三、人員登錄
簡簡單單一個登錄功能，需要考慮并涉及到很多方面，包括登錄用戶名設計（通常支持用戶名、工號、郵箱和手機）、cookie、session、token、http和https、LDAP、單點登錄、“記住我”功能設計、登錄試錯次數、登錄資訊有效期、登錄資訊是否脫敏、強制退出（踢出）、驗證碼、安全問答、密碼強度、重置密碼、語音登錄、二維碼掃碼登錄、OAuth或OAuth2、登錄安全日志等，
登錄需要注意的最大問題是資訊安全，魯迅先生說“不憚以最壞的惡意來推測中國人”，對于資訊安全，哪怕是內部人員管理系統，也要做最保守的安全防御編程，
別看登錄功能基礎且簡單，設計不好，三天兩頭出問題，別問我怎么知道的，有些公司開發的系統之讓人無語程度絕對超乎你的想象，
HCRM在設計登錄功能的時候參考了很多公司和開源專案的現有實作，并提取出精華部分加以利用，已經在生產環境得到了驗證，
HCRM這一套安全防御實作對后續開發PCRM和ECRM也有極其重要的參考價值，有空后續文章再介紹，
HCRM對外公開介面，用于用戶登錄：
每個管理后臺基于Asp.Net的安全框架實作Form認證登錄功能，
驗證碼長度可配置，可以根據實際頁面效果調整驗證碼長度，否則驗證碼圖片容易失真，
除了用戶名、密碼外，還可以通過手機、郵箱、工號等登錄，登錄功能可以擴展，支持OAuth等方式的授權登錄，
支持驗證碼的動態生成和銷毀，是否需要驗證碼以及驗證碼長度可通過配置中心動態配置來控制，
支持公共服務統一集成平臺的基于Redis加Token的登錄方式，
早期通過JWT實作用戶登錄認證基本邏輯，根據經驗，絕大多數情況下JwtToken也就是當一個加密的cookie來用，
后續隨著業務變化需要，JWT被改造為直接通過Redis+Token，實作通用的登錄、授權、鑒權、安全退出等邏輯，
四、人事管理
人事管理完全可以單獨部署成獨立應用，但是為了介紹方便，還是在HCRM里一起貼圖說明下，
個人作業過的公司基本都有一整套完善的HCRM人員管理系統，常見模塊包括人事基礎、員工檔案管理、招聘職位管理、考勤管理、薪資管理、假期管理、在線申請單據管理、報銷憑證管理、報表管理、流程管理、組織架構管理、關聯賬號管理、員工職級管理、投票管理、會議管理、合同管理、常用資料管理等等，有些還和OA整合在一起，極大地提升無紙化辦公效率，
PowerDotNet實作的HCRM系統自動集成了人事基礎和常用人事管理，中小公司基本夠用，簡單截圖看一下：
1、人事基礎
2、人事管理
人事管理中，員工工資管理模塊，對保密性、可靠性和權限控制有更高的要求，對工資的查看和操作都有詳細審計日志（日志也要脫敏），保證資料安全，HCRM已經完美支持員工工資和員工調薪管理，
當然本文重點主要介紹最常見最通用的RBAC和登錄，這是各種互聯系統中最最基礎的模塊之一，
五、總結
HCRM人員管理平臺實作了常見的豐富的可擴展的人員管理功能，主要包括人員管理、通用權限管理、人員分組管理、登錄管理、人事管理等核心模塊，
目前PowerDotNet的通用權限管理已經自動集成對接所有PowerDotNet公共服務系統，僅需要很少的模板代碼，就可以將權限控制到選單、按鈕和檔案，資料和欄位權限功能也只需要很少的業務代碼（簡單的則一行代碼也不要接入方寫，只要HCRM權限配置好SQL就行）即可自動集成，
現在新的應用想對接PowerDotNet的通用權限，僅需在管理后臺點點按鈕，后端埋點權限模板代碼，不論BS（支持VUE和React等SPA應用）還是CS結構的應用程式，整個權限設定程序不超過5分鐘就對接完成了，大大降低了權限控制門檻，
作者：Jeff Wong
出處：http://jeffwongishandsome.cnblogs.com/
本文著作權歸作者和博客園共有，歡迎圍觀轉載，轉載時請您務必在文章明顯位置給出原文鏈接，謝謝您的合作，
轉載請註明出處，本文鏈接：https://www.uj5u.com/ruanti/421663.html
標籤：其他