今天無意中在首頁中看到了四海同志的一篇《實現業務系統中的使用者許可權管理--設計篇》文章寫的非常的好，裡面的一些話似乎被其它許可權管理系統的設計轉來轉去，看上去都有種似曾相識的感覺，當然，也不排除那些文章最初是由四海同志寫的，後來被他們轉來轉去的。四海同志的文章我仔細看了下，算是看懂了吧。分析的挺透徹。我以前在b/s的許可權管理系統上研究過一段時間，有些小心得，來跟大家分享下，限於我個人能力，如果寫的不好，或**說的不對，還望朋友們指出來，千萬不要拍我。
四海同志的文章中有這樣一句話：「傳統業務系統中，存在著兩種許可權管理，其一是功能許可權的管理，而另外一種則是資源許可權的管理，在不同系統之間，功能許可權是可以重用的，而資源許可權則不能"。似乎他的那個許可權設計也沒有能夠解決資源重用的問題。當然，如果它把資源檔案分別存放在不通的資料夾中，通過url來根據許可權來判斷那就另當別論了。
我這個人比較懶，總是想用乙個通用的方法，放在**都合適，因此在資料庫的設計上費了一番腦筋了。其實，很多的許可權管理系統都不太一樣，因此，很多開發者開發出來的許可權管理系統放在別的地方，就不一定合適了，往往需要重新開發，許可權管理系統的結構不能變，變的僅僅是資料。在這樣的乙個思想的指導下，我們就想法讓我們的結構不要變，盡可能的通用，其實結構在**，還是體現在資料庫上了。四海同志說：「許可權」，「組」和「人」。而這三種元素可以任意新增，彼此之間不受影響。
而我卻認為，乙個完整的許可權管理系統應該包括：使用者、角色、模組、資源這四個部分，在資料庫的表設計上，這四張表叫做許可權管理系統的實體表，只要把這四個實體表做出來，許可權管理系統的架構就搭建完整了，這樣的許可權管理系統翻譯成中文那就是：許可權管理系統是判斷（可能用判斷這個詞不是很準確）使用者或角色對什麼資源是否有什麼功能的這樣乙個系統。這樣設計出來的許可權管理系統通用性、擴充套件性才夠強，系統足夠完整。四張實體表做好了，就意味著架構搭建好了，那麼邏輯關係怎麼辦呢？我當時設計的時候用另外的4張表來儲存他們之間的邏輯關係，總共8張表，四張實體表，四張邏輯關係表。 其它的許可權管理系統可能少於8張表，一般通用性不會太好的。通常都是在完整的基礎上做了下變化，有的利用繼承來做，有的利用位運算，還有的雖然不通用，但是也是充分利用了自身的特點，一般都會少於8張表，但是一般翻譯成漢語都不完整。通常為：使用者對資源是否有什麼功能、使用者或角色對資源是否有許可權等等。。。。切記，通用的許可權管理系統無論是使用者、角色、模組、資源哪個方面，都可以在不改變架構的條件下去動態的擴充套件，改變的僅僅是資料，而只要有這個思想，再結合自身專案的特點，相信設計和開發各種各樣不通的許可權管理系統不會有問題的。
受大家建議，附圖一張，如下所示：
通用的許可權管理系統設計
一般的企業應用系統，最重要的兩個模型是資料模型和許可權模型。資料模型根據不同的行業有所不同，而許可權模型跟行業關係不大，但是每個應用系統所必不可少的，也常常令設計者大為頭疼。如何設計乙個通用的許可權管理系統呢，如何 使這個許可權系統能夠足夠靈活，而又能適應企業不斷變化的業務呢？遵循如下原則就可以基本...
通用許可權管理設計
最近又碰到了許可權的分配和管理，需要單獨設計一套結構。其實以前有了很多的這方面的設計和博文，在園子裡面的找找看就會找到n頁的結果。這裡也不敢說是新思路吧，權當是自己的總結和留個腳印吧，方便查詢。通用在這裡有兩個概念 1 為了吸引眼球 一看到是通用就要點開看看究竟，當然了，結果無非是幾種，有人罵，有人...
通用許可權管理系統設計篇（一）
一 引言因為做過的一些系統的許可權管理的功能雖然在逐步完善，但總有些不盡人意的地方，總想抽個時間來更好的思考一下許可權系統的設計。許可權系統一直以來是我們應用系統不可缺少的乙個部分，若每個應用系統都重新對系統的許可權進行設計，以滿足不同系統使用者的需求，將會浪費我們不少寶貴時間，所以花時間來設計乙個...