技術服務於業務，良好的技術設計和實現能夠大幅提升業務質量和效率。
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分鐘就對接完成了，大大降低了權限控制門檻。