Какие рекомендации по архитектуре следует учитывать при проектировании системы разрешений на основе точек, такой как использование переполнения стека?

Question

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

Какой совет, особенно сОтносительно архитектурной реализации, вы бы дали кому-то, кто разрабатывает такую ​​систему?Где вы храните разрешения?Как вы используете эти разрешения, чтобы определить, какие поля кажутся редактируемыми в представлении?Есть ли хорошие примеры кода с открытым исходным кодом для изучения?

Что касается владения или совместного использования объектной модели, такой как вопрос или документ, каковы плюсы / минусы хранения ссылки на владельца намодель этого объекта по сравнению с хранением ссылки на этот объект в модели счета?например,

document = { id:          21234,
             owner_id:    4d3ca9f1c067,
             shared_with: [a50d1e000138, 4d3ca9f1c067a, 50d1e000138] }

против

user = { id:              4d3ca9f1c067,
         documents_owned: [21234, 31452, 12312],
         collaborates_on: [23432, 43642, 12314, 23453] }

Answer 1

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

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

Параметры модели: я бы предпочел первый, так как (1) он имеет более простую, более плоскую структуру, поэтому нет вложенных циклов в пользовательской таблице при перечислении вопросов и (2) удаление документа не повлечет за собой обновление пользовательского объекта , (Если их оценка не падает, когда документ удален или тому подобное.)