Entity Framework: справка по реляционной модели для разрешений, пользователей и т. д.

Кто-нибудь может помочь?

Я хочу создать хорошую реляционную модель для управления разрешениями.

В настоящее время у меня есть таблица «Пользователи» и различные другие таблицы, такие как «Клиенты», «Поставщики».

Пользователю необходимы разрешения на просмотр, редактирование, создание либо в разделе «Клиенты», либо «Поставщики».

Я буду использовать эти таблицы в EF, чтобы решить, какой доступ есть у пользователя, и погоду, чтобы показать форму или нет и т. д.

Моя исходная модель выглядит так, хотя я думаю, что это неправильно, поскольку в ней ничего не говорится о разрешениях.

Users UsersCustomers (содержит связь между пользователями и клиентами) UsersSuppliers (содержит связь между пользователями и поставщиками) Customers (таблица клиентов) Suppliers (таблица поставщиков).

Хотя это работает, то есть, например, связывает пользователя с клиентом... Это просто не кажется правильным.

Я думал о размещении промежуточной таблицы под названием «Разрешения», которая будет иметь идентификатор и идентификатор пользователя, которые будут связывать таблицу пользователей. Затем я мог бы связать разрешения с таблицей, например

PermissionsCustomers (вместо UsersCustomers), который будет содержать связь между разрешением и клиентами.

Я думаю, что здесь я не совсем понимаю оптимальный дизайн. Как только этот дизайн будет правильным, в нем также будет отсутствовать таблица для назначения того, какой тип разрешений пользователь имеет для клиента, т. е. «Редактировать», «Создать» или «только просмотр» и т. д.

Я хотел бы услышать отзывы или пример существующей надежной модели, которая работает так.

Что касается клиентов, поставщиков, это всего 2 примера, будет намного больше таблиц, таких как deliveryLocation, accountLedger и т.д.

Было бы здорово, если бы я мог сделать запрос, в котором говорилось бы: «Покажи мне все разрешения, которые есть у пользователя X», в настоящее время с моей настройкой мне пришлось бы запрашивать каждую промежуточную таблицу отдельно.

Я бы использовал это через ORM-подобную структуру сущности.

Немного запутался со структурой реляционной модели.

Заранее спасибо.


c# entity-framework relational-database orm database-permissions
person Martin    schedule 14.08.2011    source источник
comment
Вы действительно собираетесь поддерживать разрешения на уровне для каждого клиента и для каждого поставщика? Другими словами, если у пользователя есть разрешения для 300 клиентов и 100 поставщиков, будет ли в таблице разрешений 400 строк? Кажется, что это будет ужасно сложно настроить, а затем поддерживать. Нет ли другого способа (например, этот пользователь может редактировать всех клиентов в Огайо или клиентов с продажами > 1 млн долларов и т. д.).   -  person E.J. Brennan    schedule 14.08.2011
comment
Привет, Эй, да, это правда, но система будет содержать только 15 клиентов (это пользовательская система) и 5 ​​поставщиков. Их будет не так много.. И мне действительно нужны разрешения, данные пользователю, который может делать определенные вещи с Заказчиком/Поставщиком.   -  person Martin    schedule 14.08.2011

Ответы (1)


arrow_upward
2
arrow_downward

Учитывая, что у вас будет очень небольшое количество клиентов и поставщиков (всего 20), вам не нужна очень сложная система.

Что я сделал в подобных ситуациях, так это настроил таблицу разрешений со структурой, подобной этой:

  • UserId (идентификатор пользователя)
  • RoleId (идентификатор, который ссылается на таблицу ролей, с такими вещами, как «Редактировать клиента», «Удалить поставщика», «Просмотреть клиента» и т. д.)
  • ObjectId (это будет идентификатор, который идентифицирует любой объект, который вы хотите защитить, поэтому либо идентификатор поставщика, либо идентификатор клиента.)

Таблица ролей будет иметь:

  • Идентификатор (уникальный идентификатор относится к RoleId в таблице разрешений)
  • Имя (уникальное имя роли, например «Редактировать клиента»)

Затем каждый пользовательский объект связан с таблицей разрешений, каждый пользователь имеет несколько разрешений. Когда пользователь входит в систему, я обычно загружаю все его разрешения в список в памяти, чтобы у пользователя был список разрешений. В списке разрешений будет только ObjectId и RoleName и/или RoleId (я предпочитаю использовать имя роли, чтобы упростить чтение кода, как вы можете видеть ниже в примере).

protected bool HasPermission(long ObjectId, string RoleName)
{

//Users in the Administrator role have access to everything in the system.
if (this.IsAdministrator) {
    HasPermission = true;
    return;
}

foreach (Permission P in Permissions) {
    if (P.ObjectID == ObjectID & P.RoleName == Role) {
        HasPermission = true;
        return;
    }
}
return false;

}

затем, если я хочу знать, есть ли у пользователя разрешение на что-то, я бы сделал это:

if (myUser.HasPermission(CustomerId, "Edit Customer") {
  //allow the user to edit the customer
else
  //allow the user to only view the customer (for example)

or

    if (myUser.HasPermission(SupplierId, "Print Supplier") {
  //allow the user to print the record
else
  //give user a warning

Суть в том, что каждая «роль» должна быть уникальной, у вас не может быть общей роли «Редактировать», потому что, если у вас есть клиент и поставщик с одинаковым идентификатором, и вы хотите увидеть, есть ли у пользователя разрешение на «Изменить», вы можете получить неправильный результат. Итак, есть роль под названием «Редактировать клиента» и еще одна роль под названием «Редактировать поставщика».

Это решение не будет хорошо масштабироваться imo, но для базы данных с десятками записей, которые необходимо защитить, оно отлично работает и просто в реализации и обслуживании. Это также не настроено по-настоящему реляционным способом, т. Е. ObjectId в таблице разрешений не связан ни с таблицей поставщиков, ни с таблицей клиентов.

(Кроме того, в этом сценарии мой пользовательский объект знает, является ли он администратором или нет, администраторам не нужна настройка разрешений, они имеют доступ ко всему, поэтому поиск разрешений не требуется - экономит несколько наносекунд времени)

person E.J. Brennan    schedule 14.08.2011
comment
Это решение не будет хорошо масштабироваться: у вас есть аналогичная модель, которая хорошо масштабируется? Может быть, у вас есть права доступа к группам элементов или роли, которые выше, чем у других ролей? - person sports; 02.07.2014