Блог

В качестве упражнения в обучении .NET, я переношу некоторые простые формы в MVC и столкнулся с проблемой. Рассматриваемая форма представляет собой форму, состоящую из нескольких частей, в которой есть дополнительные разделы. Например, раздел 0 является статическим и содержит такую информацию, как имя пользователя, настоящее имя, адрес электронной почты. После этого находится переключатель с несколькими опциями. Если вы нажмете на первый радиоприемник, он отобразит раздел 1. Если вы выберете второй, он отобразит раздел 2 и так далее.

В WebForms это не имело большого значения, поскольку я просто проверил при обратной отправке и сказал, является ли Radio1.Выбрано проверить это, если Radio2.Выбранный проверяет это и т.д. Итак, теперь у меня есть строго типизированное представление с [обязательными] элементами, которое, очевидно, не сработает — я не могу требовать элементы, которые не всегда будут необходимы.

С учетом сказанного, правильный ли это подход к проблеме:

• Создайте элементы, которые принадлежат разделу 0 в моем классе модели строго типизированного представления.
• Создайте ссылки на строго типизированный класс каждого partial в моем классе view model.
• Создайте частичные представления, а затем отобразите их в главном представлении.
• В зависимости от того, какой переключатель выбран, отобразите соответствующий частичный вид.
• Проверьте модель как обычно … что, надеюсь, будет каскадно переходить к частичным моделям.

Имеет ли это смысл, или подход неправильный?

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

Это одна из причин, почему я использую FluentValidation.NET. Мало того, что правила проверки отделены от моделей представления и что они очень хорошо интегрируются с ASP.NET MVC но обработка подобных сценариев была бы очень простой. У вас могла бы быть модель вложенного представления, содержащая все свойства подраздела, а затем условно включать ее на основе значения данного свойства в модели основного представления внутри ее средства проверки.