原文地址：http://aspnetboilerplate.com/Pages/Documents/Feature-Management （在翻譯原文的基礎上增補更多細節說明）

簡介

在大多數SAAS系統中。都提供【版本】這個概念。不同的版本提供不同的功能特性。通過這種方式，一個SAAS系統可以提供不同的價格與功能組合給不同的租戶。

例如【標準版】含有A/B/C三個功能，售價1000元；【旗艦版】包含A/B/C/D四個功能，售價2000元。

ABP內置了特性（功能）模塊以簡化此類功能開發。您可以定義各種特性（功能），檢測某個指定特性（功能）是否對某個指定租戶開放，或者根據後臺設置的特性（功能）開放對應的頁面或是生成對應的導航。

在一個SAAS系統中，使用不同功能版本的租戶應該看到不同的導航菜單。例如在一個OA系統中，旗艦版的用戶有人事管理、財務管理、行政管理、知識管理四個導航菜單。但標準版則沒有知識管理這個導航菜單。即使用戶通過在地址欄直接輸入知識管理對應的url地址，系統也應該給與明確的錯誤提示：您的版本為開通此功能，如有需要，請聯系...，而不應該不做任何驗證直接使用該功能。在ABP的架構設計中，特性和版本是直接關聯的，您可以通過檢測當前用戶所屬的租戶對應的版本是否開通了當前操作對應的功能以確定是否對用戶開放當前操作。

補充：在ABP中，特性可以直接關聯到具體的租戶，也可以關聯到具體的版本。舉例：系統中一共有5個功能，標準版有1,2,3功能，旗艦版有1,2,3,4,5功能。現實情況中，有可能會出現客戶因為價格原因，購買標準版，但是又對旗艦版的第五項功能迫切需要。此時可單獨針對此租戶開放1,2,3,5四個功能（具體實現代碼後續在我們的OA中做詳細演示）。

特性值倉庫接口

特性功能通過使用IFeatureValueStore 接口來實現獲取特性的值。您可以自己實現該接口，該接口的完整實現在Module Zero項目中。如果您沒有在系統中手動實現該接口，系統默認會使用NullFeatureValueStore這個實現，在該實現中，所有獲取特性的方法都返回Null值。

此處翻譯起來很別扭，可能是我理解有誤，沒想明白作者為何要如此操作。

特性類型

系統中存在兩種基本特性類型。

布爾特性類型

值為“true”或者“false”，此類型克用於設置針對某個版本或是某個租戶開放或者關閉某個特性（功能）。

值特性類型

該類型可以存儲任意類型的值。在系統中，存儲或獲取該值時，得到的是該值的文本形式。故，在實際使用中，需要進行類型轉化。

舉個例子：假如系統是一個任務管理系統，並且限制每個月可創建的任務數。想象一下，假如系統包含兩個版本，標準版限制每月最多允許創建1000個任務，旗艦版限制每月最多允許創建5000個任務。此時，我們應該使用特性去存儲1000與5000這兩個值，而不應該簡單存儲true/false。

在實際使用中，如果一定只有兩個版本且日後不會更改，用布爾值區分特性也是可以的，但是，假如系統有三個、四個、甚至五個版本時，布爾值就不夠用了（布爾值最多允許兩個值）。

註意：系統中存儲的1000與5000是字符串格式的“1000“與“5000“，而不是具體的數字。

ABP.ModuleZero.Feature——特性管理