Хорошая идея для разрешения ролей пользователей на уровне приложений?

Question

Причина, по которой мне нужна система на основе ролей:

1. Ограничение доступа к страницам.
2. Ограничение доступа к определенным функциям на страницах.
3. Проверка / проверкавнутри сервисного слоя.

Итак, я думаю, я могу просто создать enum и, если мне нужна новая роль, просто добавить ее в код приложения (приложение все равно изменится, поэтому требуется перекомпиляция).

Так что сейчас у меня есть

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 ко многим.Плюсы, которые я вижу в этом, состоят в том, что вместо много-много есть 1-много, а объединений меньше.Приложение уже знает, на чем основана роль, на что int разрешает перечисление.

Есть ли какие-либо недостатки в том, как я это делаю?Есть ли что-то, что вы встретили в своем опыте, которое потребовало бы от меня сохранения фактических значений в базе данных?

Answer 1

Чтобы было ясно, вы предлагаете, чтобы вам не нужна фактическая таблица поиска в базе данных для ролей?Вместо этого у них просто есть int, который не является ни для кого внешним ключом - это просто представление enum в приложении?

Невозможно ответить окончательно, не зная всех деталей вашего приложения.Помимо этого заявления об отказе, я не вижу в этом ничего сложного.Это, безусловно, будет работать нормально для некоторых систем.

Возможные недостатки:

• Нет источника допустимых значений, применяемых на стороне базы данных посредством ссылочной целостности.Что мешает кому-либо ввести «12452» для RoleId в столбце базы данных?Есть и другие способы, такие как использование проверочных ограничений, но их не обязательно проще поддерживать, чем справочную таблицу.
• Нет способа эффективно запрашивать таблицы пользователей / ролей и иметь удобочитаемое представлениероли, не зная, что представляют собой RoleIds (для понимания результата запроса перед вами должен быть enum).
• Если база данных используется для других приложений, роли необходимо будет представить(и поддерживается) в этом приложении также.