在我的ASP.NET MVC3應用程序中,我有用戶,角色和實體。用戶角色將有權訪問實體。所以在將數據庫中的用戶和角色存儲在數據庫中時,以下哪個方法是好方法?asp.net mvc3用戶角色和訪問權限
要在實體表
實體ID在用戶表中存儲用戶列表。
未來實體的數量可能增加到1000,10000,所以我想考慮性能方面。
在我的ASP.NET MVC3應用程序中,我有用戶,角色和實體。用戶角色將有權訪問實體。所以在將數據庫中的用戶和角色存儲在數據庫中時,以下哪個方法是好方法?asp.net mvc3用戶角色和訪問權限
要在實體表
實體ID在用戶表中存儲用戶列表。
未來實體的數量可能增加到1000,10000,所以我想考慮性能方面。
我認爲角色和實體之間的關係是多對多的。一個角色可以有零個或多個實體,一個實體可以屬於零個或多個角色。因此,創建一個第三個表來存儲那些具有2列,RoleId
和EntityID
的樣本數據會看起來像
ROLE_ID ENTITY_ID
-----------------------------------
1 144
1 146
2 194
4 14
4 194
在您需要爲您的應用控制的粒度依賴你可能要考慮模型在Windows Identity Foundation(WIF)中使用,現在它已成爲.NET Framework 4.5的一部分。這是一個claims-based architecture和用於您所調用的術語實體是資源。與您的模型不同的是,他們也有操作的概念。 A 資源可能有許多操作,並且典型操作將類似讀,寫,執行。這是控制的粒度更細的用武之地。
因此,在這種情況下,操作特定資源可以有很多角色和角色可以有很多操作,需要另一個表來映射這種多對多的關係。使用int作爲主鍵角色和操作作爲對象ID對性能有好處。 用戶可以有很多角色和角色將有許多用戶,所以再次,你會需要另一個表來管理這許多一對多的關係。
所以答案問題1是你沒有的用戶列表存儲在該實體表。你有一個單獨的用戶表映射到表用戶到角色,它映射到角色,它映射到角色到操作,它映射到的操作一個表,該表映射到表資源。如果您不需要的粒度操作消除該表並將您的角色到資源通過另一個表來處理這種多對多關係。
回答問題2是否定的,你就不會在用戶表的實體(資源)的標識。 A 用戶通過我上面描述的關係被映射到資源。
使用此模型和基於聲明的架構的完整程度,最好的方法是不分配角色使用AuthorizeAttribute你的方法,這是怎麼了,在過去是典型的做法。而是將資源和操作分配給將您的安全策略與應用程序分離的方法。對於這種方法的模型,請看ClaimsPrincipalPermissionAttribute。您可以創建使用此方法的自定義AuthorizeAttribute。