Question

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

限制对网页的访问。
限制对网页上某些功能的访问。
检查/验证服务层内部。

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

现在我有

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; }
}

这是一对多。我看到的优点是，不是很多，而是1-many和join更少。应用程序已根据int解析枚举的内容知道角色是什么。

我这样做的方式有什么缺陷吗？您的经验中是否有任何需要我将实际值存储在数据库中的内容？

Answer 1

要明确的是，您建议在数据库中不需要实际的查找表来获取角色？相反，它们只有一个不是任何外键的int - 它只是应用程序中枚举的表示形式？

如果不了解申请的所有细节，就无法回答。除了这个免责声明，我认为没有任何内在问题。它肯定适用于某些系统。

可能的缺点：

通过参照完整性在数据库端没有强制执行有效值的来源。什么阻止某人在数据库列中输入RoleId的“12452”？还有其他方法可以使用检查约束，但它们不一定比查找表更容易维护。
无法有效地查询用户/角色表，并且无需知道RoleIds代表什么就具有人类可读的角色表示（您必须在您面前使用枚举来理解查询结果）
如果数据库用于其他应用程序，则还需要在该应用程序中表示（和维护）角色。

在应用程序层中解析用户角色的好主意？

1 个答案: