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

Question

Я хочу опубликовать комментарий к принятому ответу на этот вопрос: " У вас нет просмотров оставленного кода? Так что вы собираетесь тестировать? ", указывая, что это мне кажется, как только вы добавите

<% if (Model.Thing == "abc") {} %>

или

@if (Model.Thing == "abc") {}

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

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

Answer 1

Постарайтесь уйти от мышления, основанного на коде Webforms. Нулевые проверки данных модели должны обрабатываться в контроллере. Представление должно содержать минимальную (или отсутствующую) логику для такого рода проверки.

public ActionResult YourAction(YourModel ym)
{
    if (ym.Thing != null)
        return View(ym);
    else
        return View();
}

Или какой бы тип проверки вы ни делали для данных. Таким образом, в вашем View не будет завалено проверкой данных модели. Это все часть разделения интересов в дизайне MVC.

Answer 2

IMO, вы должны защищать только от null, index oob и т. Д. В своих представлениях, если вы ожидаете, что значения будут null, oob и т. Д.

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

Answer 3

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