Обслуживание страниц с ошибками в MVC: контроль или представление?

Question

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

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

некоторые примеры:

• Путь запроса не имеет смысла, поэтому мы хотим ответить пользовательской страницей "not found".
  • Элемент управления выбирает представление "не найдено" и использует свой ответ
  • Элемент управления создает саму страницу "not found"

.

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

Теперь разница между первыми двумя вариантами в обоих случаях техническая / организационная, и для пользователя, вероятно, нет никакой разницы. Существует ли стандартное мнение по этому поводу (возможно, в рамках MVC) или выбор просто произвольный? Какой метод предпочтительнее?

Answer 1

Контроллер успешно выбирает представление, но оно генерирует исключение.

Если следовать шаблону проектирования MVC, это никогда не произойдет.Единственная логика, которая должна содержаться в представлении, это исключительно логика отображения (форматирование, локализация и т. Д.).

Ошибки должны отлавливаться либо на уровне модели, либо на уровне контроллера, но контроллер должен решить, что делатьс пользователем (redirect / 404 / etc).

Редактировать:

Конечно, это не единственный способ ... Я уверен, что вы можете найти взломанубитый код повсюду, который делает разные вещи.Насколько мне известно, да - ваши представления должны быть спроектированы таким образом, чтобы не нужно было перехватывать ошибки (кроме ошибок ajax / javascript, но в любом случае они к этому относятся).

Iобычно настраивают его так, чтобы у меня было другое представление для каждого кода ошибки HTTP, который я хочу обработать, и общее для универсального кода.В этом случае контроллер будет нести ответственность за передачу данных об ошибках в представление для рендеринга (обычно в виде массива).Конечно, это также может быть сделано с помощью ErrorModel (который будет «правильным» способом его реализации - я просто ленивый;))

Answer 2

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

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