具體資訊系統防護罩

[img index=1]
一直有個糾結的問題是Anycmd許可權引擎中有大量的小類，Command和Event類 和Input、Output類都是小類。這些小類的唯一作用只是在匯流排上傳遞的資料的載體。很想把這些小類都去除然後使用Dictionary<string, object>去取代。但是不知道這兩種方式到底哪個更好管理？哪個效率更高？這些具體的Command和Event .NET型別資料可以用來對訊息（包括Command和Event）進行分類（class的本質是對人類使用了上萬年的古老分類法的應用，分類的是執行時物件），然後在匯流排上可以透過這種基於.NET型別的分類來路由它們，基於.NET型別來登記訊息型別，釋出、訂閱訊息。

考慮是否讓承載資料的小型別回老家？

然而我在Dictionary<string, Object>字典中新增個key為“MessageSubject”的項一樣可以啊。而且Subject才是個更準確的詞彙，對於Event來說，釋出訂閱時使用的詞彙是Subject而不是.NET型別。
如果使用Dictionary<string, Object>取代.NET型別的話我們可以把Dictionary<string, Object>的Key提取出來持久化到資料庫管理。

Anycmd許可權引擎的額外收穫
.NET版本的Anycmd寫完後我大致明白如何把它投射成java、nodejs、golang、rust等多種版本了，不只能做到介面層使用起來是一樣的，甚至能做到原始碼都是相似的。

希望減少人們以後在系統的訪問控制方面的糾結。anycmd設計的足夠抽象，也會編碼到拿來即可使用的地步，理想是人們在開發業務系統的時候再也不用書寫任何訪問控制邏輯，只需在上線執行前安裝上許可權引擎驅動的一個防護罩就萬事Ok了。

具體資訊系統防護罩
可以取個名字叫“具體資訊系統防護罩”。
許可權引擎是永遠開源免費的，如果你針對某個具體業務領域配置許可權引擎，你配置出那個具體領域的資源、功能、角色等資料，你初始化許可權引擎，你推出的“某某資訊系統防護罩”可以收費。

許可權引擎官方不參與上層建設

許可權引擎是底層事物，上層會有很多可能付費獲得的事物：比如許可權引擎管理系統（類似那個AnycmdMisSite專案，不由anycmd官方提供，任何人可以提供）、比如管理系統的UI框架、比如將許可權引擎應用到具體的業務系統（幫助配置、開發）……所有的這些業務都不是官方提供的，任何人可以提供。
官方只負責構建許可權引擎，如果官方提供買賣平臺的話，官方只靠5%-8%的服務費維持。

困難

我搜尋過可靠許可權系統設計者的言論，他們從來沒有說過“業務許可權”神話不可打破，只是說實現起來有困難。