ОК, так что, может быть, я действительно чего-то здесь упускаю, но как так сложно провести эффективную проверку на стороне сервера и клиента в MVC (2)? Вот несколько примеров:
Я хочу использовать список переменной длины. Я следую замечательному учебнику, например, обзору списка переменных длин Стива Сандерсона. Я хочу создать собственный валидатор, такой как «RequiredIf». Мой список переменной длины представляет собой коллекцию (с использованием HTML-помощника Сандерсона для коллекций), и пользовательские средства проверки не запускаются даже при наличии правильных клиентских сценариев проверки (которые отлично работают для списков без переменной длины). . не является ли список переменной длины, который необходимо отправить обратно, как перечисляемая коллекция в действие [HttpPost] довольно распространенным? Почему эта проверка настолько болезненна на стороне клиента - если вы хотите получить аннотацию проверки, которая была связана с вашим классом? В этом случае проверка на стороне сервера действительно работает ... но на стороне клиента кажется невозможным использование коллекции и списка переменной длины. Конечно, это может быть связано с именованием идентификатора элемента HTML из index-Guids коллекции, но оно начинает становиться настолько запутанным ...
У меня есть ViewModel, которая может быть заполнена различными типами данных. Я хочу проверить в некоторых случаях, но не в других. Обычно я заполняю свою ViewModel из класса домена, в котором уже есть аннотации данных для проверки. Однако для корректной проверки ViewModel потребуются собственные аннотации данных. Для некоторых полей я хочу проверки, но для других применений того же поля - при заполнении другими данными - я не хочу проверки. Я не могу ссылаться на динамическое свойство в моей аннотации проверки данных, хотя ... аннотации являются статическими. Это должно быть основано на том, когда они связываются и т. Д. Конечно, я могу сделать собственный валидатор, который будет ДЕЙСТВИТЕЛЬНО сумасшедшим и на самом деле ссылается на литеральные значения других полей, пытаясь решить, следует ли проверять (рисует в логических значениях «требуется» и строки для "регулярных выражений" или "сообщений об ошибках") ... но ой! Серьезно, это так сложно?!
Что расстраивает, так это то, что чем больше я пытаюсь следовать шаблонам, предоставляемым MVC, я продолжаю сталкиваться с вещами, которые МОГУТ быть чертовски простыми, но становятся такими болезненными, когда вы не можете отклониться от шаблона. Если аннотация проверки данных является правильным подходом, на самом деле кажется, что она должна поддерживать динамически установленные свойства и иметь лучшую автоматическую визуализацию клиентского JS (особенно для пользовательских валидаторов), чтобы избежать этих головных болей. Я почти закончил, пытаясь заставить проверку на стороне клиента работать в этих ситуациях.
Кто-нибудь использовал пакет проверки, который облегчает этот процесс? Я недостаточно знаком с поддержкой пакетов валидации, совместимых с MVC 2, чтобы знать, стоят ли они того. Например, я просмотрел Fluent Validation, но мне нужно больше узнать. Позволяет ли динамическое назначение валидации и клиентское валидация для пользовательских валидаторов?
Одна идея, которую я рассматриваю, заключается в простом добавлении полей данных в моей модели предметной области, которые предоставляют доступную для просмотра строку, которую может подобрать и использовать пакет, такой как валидация JQuery, чтобы избежать всей упомянутой выше ситуации. Таким образом, моя модель домена может использовать аннотации для защиты своей целостности данных (и будет служить конечной остановкой для любой проблемы вставки), и моя клиентская сторона может просто иметь строку, которую нужно выбросить в атрибут класса для использования сценарием валидатора без необходимость пройти через сумасшествие предоставления пользовательских валидаторов на стороне клиента с кучей излишеств / интерпретации «IEnumerable GetClientValidationRules () ...»
Что дает? Есть ли лучший способ?