0

我需要基于角色的系统的原因：

  1. 限制对页面的访问。
  2. 限制对页面上某些功能的访问。
  3. 服务层内部的检查/验证。

所以我猜，我可以创建一个枚举，如果我需要一个新角色，只需将它添加到应用程序代码中（应用程序无论如何都会更改，因此需要重新编译）。

所以现在我有

public class User
{
   /* .. */
   public virtual ICollection<UserRole> Roles {get; set;} 
}

public enum UserRoleType
{
    Administrator,
    User
}

public class UserRole
{
    public int UserRoleId { get; set; }

    public int RoleTypeValue { get; set; }

    public UserRoleType RoleType
    {
        get { return (UserRoleType)RoleTypeValue; }
        set { RoleTypeValue = (int)value; }
    }

    public virtual User User { get; set; }
}

这是一对多。我看到的优点是，不是多对多，而是一对多，并且连接更少。int应用程序已经根据枚举解析的内容知道角色是什么。

我这样做的方式有什么缺陷吗？根据您的经验，您是否遇到过任何需要我将实际值存储在数据库中的情况？

4

1 回答 1

1

为了清楚起见，您是在建议您不需要数据库中的实际查找表来查找角色？相反，它们只是有一个 int，它不是任何东西的外键——它只是应用程序中枚举的表示？

如果不了解您的应用程序的所有细节，就不可能做出明确的回答。撇开免责声明不谈，我认为它本身没有任何问题。它肯定适用于某些系统。

可能的缺点：

  • 没有通过参照完整性在数据库端强制执行的有效值的来源。什么是阻止某人在数据库列中为 RoleId 输入“12452”？还有其他方法可以解决这个问题，比如使用检查约束，但它们不一定比查找表更容易维护。
  • 在不知道 RoleId 代表什么的情况下，无法有效地查询用户/角色表并具有人类可读的角色表示（您必须在您面前有枚举才能理解查询结果）。
  • 如果数据库用于其他应用程序，则角色也需要在该应用程序中表示（和维护）。
于 2011-09-22T18:24:20.707 回答