2011-10-20 35 views
2

在嘗試爲Web應用程序實現基於角色的安全性時,我在權限,角色,用戶和UserRole(即將用戶分配給角色)的數據庫中有一個表。使用標誌枚舉進行權限的缺點是什麼?

每個角色都有一組權限。權限被定義爲一個C#標記枚舉值,如0,1,2,4等。

在數據庫中,角色表具有一個int字段,該字段存儲角色的組合權限標誌。 (通過這種方式,我們避免了單獨的權限表(是好還是壞?)和一個用於RolePermissions的一對多表。

在代碼中,我通過計算有效權限來檢查用戶是否有權訪問角色(一個或多個)用戶被分配到在.NET中這是很容易做到這一點做的枚舉標誌邏輯運算

所以我的問題是:。

有一個缺點做這種方式(與擁有Permission表和RolePermission鏈接表(其中包含給予角色的每個許可的1個記錄)相反)?

回答

1

三個直接的缺點:

  • 標誌只能包含儘可能多的項目,因爲有可用的位。
  • 從數據庫查詢現在變得更煩人了。那麼,只有當你手動使用SQL時(一個連接到角色表來確定成員會讀得更好)。
  • 當數據不是作爲標誌查看時,是否有人會記住第四位數值爲1的數值是什麼意思?

讓生活變得輕鬆,並與一個單獨的列表。被分配到一個集合可以很好地歸結爲myPermissions.Contains(new Permission("CanEdit"))。然後,您可以使用各種轉換例程將硬編碼的值(例如枚舉或字符串)轉換爲實現myPermissions.Contains("CanEdit")等的權限的對象表示。

這並不是說在選擇分隔表上的標誌時會有性能影響,反之亦然我不知道你在看什麼樣的用法。

+0

感謝。用法不太奇特。它是一個多租戶的Web應用程序,每個租戶都希望定義他們自己的角色名稱並將他們的用戶分配給他們的自定義角色。他們當然需要爲每個自定義角色分配一組標準權限。 – Krishna

1

唯一的缺點是,你最終會寫更多的代碼,以檢查權限。擁有一個帶用戶角色的獨立表格可以很容易地確定它們。

  • 優勢:(?但誰在乎此此 情景)節省存儲空間
  • 缺點:在你的代碼更復雜。
+2

我實際上認爲代碼更簡單。這只是根據需要和/或權限的問題。 – Krishna

1

我使用了一個標誌枚舉,就像3年前在一個項目中描述的那樣。我的考慮:

  • 創建一個層來簡化使用,否則你會在前端
  • 它不直觀「新的開發者有亂碼結束。如果其他人會維護這些代碼,請注意他可能會錯過整個想法並引入更多複雜性和/或錯誤...

詩:

每個角色都有一組權限。權限被定義爲一個C#標記枚舉值,如0,1,2,4等。

NEVER在一個標誌枚舉使用0 ...