許可權管理需求
it系統不斷向前發展，企業對於it資訊系統的許可權控制要求越來越嚴格。主要有以下幾類：
功能控制。比如允許某些使用者使用某功能，訪問某頁面。拒絕某些使用者使用某功能，訪問某頁面。
更細粒度的控制。
資料行控制。同樣的功能，不同使用者訪問的資料範圍是不同的。比如總公司使用者能檢視所有客戶資料；分公司使用者只能檢視本分公司及下屬營業部客戶資料；營業部使用者只能檢視本營業部客戶資料。
資料列控制。同樣的功能，不同使用者訪問的資料字段是不同的。比如總公司使用者不能檢視客戶資料的聯絡**和聯絡位址資訊，可以檢視客戶其他字段資訊；其他使用者能檢視客戶的全部字段資訊。
資料操作許可權控制。比如銀行atm機器，不允許每天取款超過2萬，單筆不超過5千；比如客戶經理只能修改和刪除自己開發的客戶資料，不能修改其他客戶經理開發的客戶資料。
介面顯示要素控制。比如顯示自己開發的客戶列表後面顯示「修改」和「刪除」按鈕，否則不予顯示。比如總公司使用者登入，機構下拉框顯示所有組織機構；分公司使用者登入顯示本分公司及下屬營業部機構；營業部使用者登入顯示該營業部機構。
許可權管理分類
綜合來說，可以把許可權需求分類兩大類：
功能級許可權；
細粒度許可權，又被稱為資料級許可權，內容級許可權。這些許可權根據登入使用者、運算元據、當前環境等條件進行不同許可權授權。可以分為：
查詢許可權；返回使用者具有許可權查詢的資料。資料行控制，資料列控制，都屬於查詢許可權。部分介面顯示要素控制，屬於查詢許可權。比如下拉框顯示組織機構，可以先返回使用者具有許可權的機構，然後填寫下拉框內容。
決策許可權；返回使用者是否具有某許可權，如果不具備該許可權，並告知拒絕理由。資料操作許可權控制，部分介面顯示要素控制都屬於決策許可權。atm先判斷使用者是否具有該取款額的許可權，然後根據結果吐錢。介面先判斷使用者是否具有「修改」和「刪除」該客戶的許可權，然後根據結果顯示按鈕或者不顯示按鈕。
如何在it系統實現許可權管理
功能級許可權控制，採用目前的角色策略即可。如下圖所示：
（圖1：角色授權策略）
資料級許可權控制，大多系統採用硬編碼模式實現，在程式裡面做各種判斷。如下圖所示：
（圖2：硬編碼模式實現細粒度許可權控制）
有些優秀企業做了傑出創造，使用配置模式，或者採用部分程式設計＋部分配置模式實現。
有些優秀企業做了傑出創造，採用在二次開發平台上，進行相關配置，然後生成帶有許可權的**，將這些**隨同應用一起發布。
目前業內有乙個非常牛氣的規範：oasis組織制定的xacml（extensible access control markup language）
規範。該規範非常強大，同時也難懂，實施難度大。
oracle entitlement server和ibm tivoli access manager都是基於該規範開發的產品。
metadmin access manager是基於策略模型開發的產品。
怎樣改進創新
待續......
簡說狀態模式
在狀態模式中，抽象狀態介面，定義統一的方法型別。子類實現該介面，補充具體的實現行為。乙個物件類，內部有狀態例項，並且有切換狀態的成員函式。當接收到外界的值 改變因素 時，在物件類的內部實現動態的狀態切換。塊 狀態模式 public class test 具體狀態實現a class statea im...
文案寫作 簡說
做產品離不開寫寫寫，寫些什麼呢！當然是各種文件嘍，有那麼幾個寫到懷疑人生有木有，反正我是常有的，說邏輯好，我邏輯算不上一頂一的好，但是算不到差的裡面，但是有一些邏輯有時候還是會把自己給繞進去，所以說文案寫作能力一定程度上會幫助你梳理你混亂的邏輯，也會幫助你更好地表達，到目前為止，我依舊不認為我的文案...
響應式布局簡說
簡單說呢就針對不同的螢幕解析度應用不同的css樣式。比如在電腦 pad裝置上，螢幕比較寬，就可以一行放2個div。到了手機上，或者pad豎著拿的的時候，一行就只放1個div。這裡有2個關鍵點 一是如何在不修改dom結構的前提下調整布局。二是如何判斷螢幕解析度並應用對應的css。以上兩點都應該不依賴與...