логика перед диспетчером + контроллер?

Question

Я полагаю, что для типичного веб-приложения MVC процедура маршрутизатора / диспетчера используется для определения того, какой контроллер загружен, в основном на основе области, запрошенной пользователем в URL.

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

Но это довольно нестандартный дизайн?Будет ли это нарушать MVC в любом случае?Я только спрашиваю, поскольку в примерах, которые я прочитал в эти выходные, не было выполнено крупных вычислений перед процедурой диспетчера, и я обычно проверяю, вошел ли пользователь в систему или нет для каждого контроллера, а затем перенаправляет при необходимости.

Но мне кажется странным перенаправить зарегистрированного пользователя из области входа в область учетной записи, если вы могли бы просто загрузить контроллер учетной записи в первую очередь?

Надеюсь, я объяснилМои сообщения достаточно хорошо, но кто-нибудь может предложить некоторые подробности о том, как они обрабатывают вошедших в систему пользователей, и аналогичные данные сеанса?

Answer 1

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

Answer 2

Это кажется справедливым требованием и может быть достигнуто с помощью перехватывающего фильтра. Заголовок запроса может быть проверен и помечен как попытка входа в систему или помечен как злонамеренная попытка. В качестве альтернативы диспетчер может делегировать это другому контроллеру, который может сделать то же самое и перенаправить запрос соответствующим образом. MVC все о разделении интеллекта в приложении. Этот случай подпадает под проверку работоспособности (техническое требование, а не деловое требование).