其實這個設計是已經做過了，那個時候我才進公司還在試用期，給我的第乙個任務就是許可權管理模組，本來之前有人做了一點，但是發現滿足不了局方要求，於是我就重新設計了這樣子乙個模組出來，當時為了趕進度也沒有怎麼設計，實現即完成，但是現在發現其實還是可以把這個模組抽象出來，設計成乙個更加通用化的設計，起碼能做乙個可復用的元件出來。
歷史的沿革就是這個樣子。現在脫產了還真是有點懷念編碼的日子。
好了，首先我們來看看是怎麼樣乙個設計，首先上其實基礎還是很常用，角色-許可權 模型，主要是.net原生的許可權管理用起來相當的麻煩而且功能有點弱，呵呵。
這裡我覺得操作員可以理解為使用者，我們所需的只是乙個id就行了，這樣子的話可以最大量的降低元件的藕合性
資源和角色都是自包含的，這樣子可以無限級的分類下去，角色的分級可以支援實現可繼承得許可權的能力
資源還可以用乙個表來表示分類，不過因為分類就那幾個，就用字典代替好了，這裡我們約束有這幾種資源，目錄，頁面，控制項，分別用0，1，2來分別表示。
粒度細到控制項的許可權管理系統的設計（概要篇）
其實這個設計是已經做過了，那個時候我才進公司還在試用期，給我的第乙個任務就是許可權管理模組，本來之前有人做了一點，但是發現滿足不了局方要求，於是我就重新設計了這樣子乙個模組出來，當時為了趕進度也沒有怎麼設計，實現即完成，但是現在發現其實還是可以把這個模組抽象出來，設計成乙個更加通用化的設計，起碼能做...
粒度細到控制項的許可權管理系統的設計（概要篇）
其實這個設計是已經做過了，那個時候我才進公司還在試用期，給我的第乙個任務就是許可權管理模組，本來之前有人做了一點，但是發現滿足不了局方要求，於是我就重新設計了這樣子乙個模組出來，當時為了趕進度也沒有怎麼設計，實現即完成，但是現在發現其實還是可以把這個模組抽象出來，設計成乙個更加通用化的設計，起碼能做...
二 測試的粒度，我們到底應該把粒度控制到多細？
對於資料不穩定的討論 url 是不是一定要測試到具體數值才叫具體？在沒有找到新方法之前，想保證測試具體到結果或者說是數值準確，那這個測試 會表現的非常脆弱，而花費了很多心思去寫出完美的測試最後這段測試 也沒有測出任何問題，有些得不償失了。為什麼要寫測試？都是為了寫出健壯的 正確的行為，獲得重構的勇氣...