Авторизация объектной модели - вопрос проектирования ОО

Question

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

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

Вопрос Каков наилучший способ применения ограничений учетной записи? Мы хотим, чтобы она была абстрагирована от реальной логики представления, но мы не думаем, что это обязательно хороший подход - поместить логику авторизации в объект Project, потому что тогда это зависит от объекта User. Что вы, ребята, думаете?

Пример: (код страницы aspx позади)

Project oProject = New Project(projectId); //Pass an Int32 here
if (oProject.Load()) //This operation needs to check user permissions somehow
{ /* Do stuff */ }

Answer 1

Вы можете реализовать класс, отвечающий за проверку разрешений для проекта (т. Е. Логика проверки разрешений будет существовать вне проекта); например В Java:

public interface EntitlementsManager {
   void checkProjectPermission(String userName, int projectId) throws SecurityException;
}

Затем в своем коде вы просто добавляете вызовы checkProjectPermission на бизнес-уровне, прежде чем передавать результаты обратно на уровень презентации. Конечно, это довольно процедурный (то есть не-OO) подход, но он понятен, поскольку вся ваша логика, основанная на разрешениях, находится в одном классе. Подход, основанный на исключениях, также означает меньшее количество операторов if-then в вашем коде.

Answer 2

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