前一段公司準備開發乙個二期專案，打算在原來的基礎上新增一些功能模組，並且能夠適合更多種使用者使用。這樣就面臨乙個問題，許可權的設計問題。原來只是簡單的分了幾個角色，根據不同角色，分配不同的功能模組。這個讓我想起了以前在學校做專案的時候，簡單的分使用者型別。沒有想到來公司做專案後，還是使用這種，寫死的東西，根本沒法重用。
後來我提出了乙個假設，如果我要新增加乙個角色，要重新給他分配功能(在原來已有的功能基礎上)，因為是在已有的基礎上，自然希望能夠不修改**，直接分配，這個時候，寫死的東西就相形見絀了。
其實當初做畢業設計的時候，我的指導老師曾經提出過，使用字串來管理許可權，字串的每一位對應乙個功能，這樣的話，許可權分配會相對於比較靈活。其實，一開始也是把角色寫死，給固定的許可權串，我的畢業設計師做乙個bs專案，是乙個asp.net的**。所以根據字串動態生成頁面，只不過每個角色對應的許可權字串是固定的。然而這只是乙個開頭，由於需求一直在變化，我天天改許可權字串，我感覺很煩，就開始考慮，能不能動態修改許可權字串(當然了，增加乙個功能模組，肯定要改的，因為字串要加一位)。
經過一番思考，我把角色放在資料庫中，建立乙個角色表，role(流水號，角色名，角色許可權串)。同時又建立乙個許可權串表。permissionsstring(字元位置，aspx位址，功能描述)。根據這倆張表，當乙個使用者登入的時候，獲取對應的許可權串，再拆分許可權串，獲取每一位許可權對應的功能，跟生成乙個string字串，動態載入頁面。其中字串「01010111...」這種形式，0，代表沒有這個功能；1，代表有這個功能。所以1，就會獲得許可權串表中對應的aspx位址，0的話，就跳過。
上面是動態生成首頁，根據許可權串，分別獲得不同的鏈結。而修改角色的許可權，可以使用checkbox，獲取乙個角色對應的許可權串，動態生成頁面，然後，打鉤就獲取該功能。下面是以前動態生成角色許可權管理的**，減少了很多，主要還是想說的是，可以動態修改許可權。
public string getprivilege1()
else
}如果要新增加乙個角色，就可以動態的為這個新增的角色選擇功能。
而上面的是我當時做畢業設計時，總結的，後來我看了狀態模式，我又重新構思了一下，發現可以去掉許可權串表（permissionsstring），只留下乙個角色表（role）。而結合狀態模式。把每乙個子字元看成乙個狀態，其中字元內容(0,1)和字元位置(int)是狀態的兩個屬性。如果增加功能模組，就可以增加乙個狀態。同時，許可權字串設長些，沒有的預先設為」0「。
這些都是一些個人想法，如果大家覺得**不對，可以指出來，一起討論。
設計模式 狀態模式
狀態模式 當乙個物件的內在狀態改變時允許改變其行為，這個物件看起來像是改變了其類。狀態模式主要解決的是當控制乙個物件狀態轉換的條件表示式過於複雜時的情況，把狀態的判斷邏輯轉移到表示不同狀態的一些列類當中，可以把複雜的判斷邏輯簡化。當乙個物件的行為取決於它的狀態，並且它必須在執行時刻根據狀態改變它的行...
設計模式 狀態模式
1.概述 當乙個物件的內在狀態改變時允許改變其行為，這個物件看起來像是改變了其類。2.解決的問題 主要解決的是當控制乙個物件狀態轉換的條件表示式過於複雜時的情況。把狀態的判斷邏輯轉移到表示不同的一系列類當中，可以把複雜的邏輯判斷簡單化。3.模式中的角色 3.1 上下文環境 context 它定義了客...
設計模式 狀態模式
描述 允許物件在內部狀態改變時改變它的行為，物件看起來好像修改了它的類。主要解決的是當控制乙個物件狀態轉換的條件表示式過於複雜時的情況。把狀態的判斷邏輯轉移到表示不同的一系列類當中，可以把複雜的邏輯判斷簡單化。通常應用在有好多狀態的流程中。類圖 以下程式模擬糖果機器投幣取糖果的狀態流程。1.定義狀態...