Где вторичные данные (такие как авторизация / идентификация) должны обрабатываться в приложении - PullRequest
0 голосов
/ 24 марта 2009

При создании сайта мой шаблон часто выглядит следующим образом:

  1. Контроллеры (сервисы приложений)
  2. Услуги (доменные службы, инфраструктурные услуги)
  3. Хранилища

Контроллеры общаются с доменными службами или службами инфраструктуры, а доменные службы могут общаться с репозиториями, службы инфраструктуры обертывают такие вещи, как SMTP и т. Д.

В настоящее время я работаю с идентификацией как с инфраструктурным сервисом, если сервису инфраструктуры или доменному сервису необходимо выяснить, «кто является инициатором», он будет запрашивать сервис идентификации при создании, у сервиса идентификации будут методы / свойства для идентификации invoker, таким образом у меня есть, например, HttpIdentityService, который определяет идентичность по данным сессии / cookie.

Однако я немного застрял в том, как обрабатывать результаты вызовов службы, например ... У меня может быть служба ArticleService, которая имеет метод CreateComment, который просто принимает текст комментария к строке и идентификатор для целевой статьи.

Моя служба приложений (контроллер), вызывает эту службу, возможно, так:

public ActionResult AddComment(int articleId)
{
  string commentText = ...;
  articleService.CreateComment(articleId, commentText);
  ...
}

Однако этот метод может завершиться ошибкой, если текущая идентификация не авторизована или не проходит политику, которую проверяет ArticleService (например, возможность комментировать каждые 30 секунд), выбрасывая и перехватывая исключения из вызовов службы, подобные этой кажется очень неправильным, потому что мой вызывающий код не может проверить, действительно ли он может успешно вызвать это действие (исключая фатальные исключения в приложениях) ..

Итак, изначально я начал заставлять сервисы возвращать «результат», результат был бы уникально идентифицирован, чтобы вызывающий мог знать, был ли комментарий действительно сделан (и дополнительно я бы возвращал сущность комментария в результате), результаты будет также определять такие вещи, как «не удалось опубликовать, поскольку пользователь не аутентифицирован», или «не удалось опубликовать, поскольку указанный период охлаждения не был соблюден» (на самом деле я не возвращаю строки, но вы поняли идею).

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

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

Заранее спасибо, Стив.

Ответы [ 2 ]

0 голосов
/ 24 марта 2009

Используйте Аспектно-ориентированное программирование для проверки привилегий. Если это не сработало, выведите исключение.

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

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

Изменить: Что касается вопроса в комментариях о том, как сообщить причину, по которой действие не разрешено: я бы использовал объекты. Если набор возможных причин является фиксированным набором во время компиляции, используйте enum. Если не просто создать небольшой класс, который может содержать все соответствующие значения.

0 голосов
/ 24 марта 2009

В аналогичной ситуации я использовал аспекты, чтобы проверить, авторизован ли вызов метода, и выдал исключение AuthorizationException, если это не так. Аспект перехватывал вызовы методов, извлекал информацию о пользователях из сеанса, проверял набор ролей / разрешений и, в конце концов, вызывал исключение. Таким образом, каллиграфический код может обрабатывать исключение, чтобы обеспечить значимую обратную связь с пользователем, регистрировать инцидент, что угодно.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...