Представления MVC3: Обработка нулевых моделей с изяществом

Question

Слишком часто я сталкивался с ситуацией, когда представление в моем проекте выдает исключение нулевой ссылки .

@model Johnny.Application.TestModel
<div>@(Model.SomeText)</div>

Выдает ошибку, если Модель равна null .

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

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

По разным причинам некоторые представления могут захотеть обрабатывать нулевые значения. Я не ожидал, что это будет в большинстве случаев. Очевидно, что это вопрос установки какого-то «контракта» между представлением и контроллером.

Мне не нравятся варианты, которые я видел:

1. Проверять, является ли модель нулевой каждый раз, когда она используется. Очень хромой !
2. Один большой оператор if , охватывающий весь вид с нулевой моделью проверять. Подумайте о потраченном впустую коде недвижимости. Lame!
3. Добавьте если проверить с броском вверху. Неплохо, но кажется глупым. Мягко хромает.

Я бы хотел знать, существует ли что-то вроде этих опций для установки контракта "нет нуля":

• Атрибут в методе контроллера, например [NoNullModels]. Я сомневаюсь, что это существует, так как я не думаю, что контроллер знает, к какому виду он подключается.
• В представлении такой индикатор, как @ MVC3.HeyDontAllowNulls или какой-либо другой стандартный способ генерирования исключения (как вариант 3 выше)

Answer 1

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

Answer 2

Я проверяю на пустые значения в своих представлениях иногда в тех частях, которые требуют этого.

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

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

Answer 3

Здесь есть много предпочтений, некоторые из которых вы можете сделать так:

1. Создайте исключение RecordNotFoundException в вашем слое данных (пользовательское исключение) и иметь глобальный фильтр исключений, перехватывающий эту
2. Проверкадля нулей, возвращающихся из вашего хранилища и обрабатываемых в сценарии для каждого конкретного случая
3. Украсьте свои контроллеры для поиска нулевой модели в методах GET, которые не являются методами CREATE (или какими-либо правилами, которые вы считаете ОК) с действиемАтрибут фильтра для проверки этого в OnActionExecuted

Даже мои представления "CREATE", как правило, получают модель, даже если они пусты (хотя довольно часто содержат IEnumerable ), поэтому они всегда должны иметьмодель едет к ним.