Andrey on .NET

Как и было обещано, давайте посмотрим вариант применения собственной реализации провайдера метаданных Модели. Кроме того, создадим еще один класс Модели для новых демонстраций.

Продолжим рассматривать возможности ядра ASP.NET MVC 3 для работы с Моделью. В этот раз давайте разберемся, что содержится в её метаданных и откуда берётся эта информация.

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

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

Никогда не доверяйте значениям, которые ввели пользователи. Сколько раз вы слышали эту фразу? А сколько раз следовали ей? В процессе работы веб-приложения вполне может встретиться ситуация, когда передаваемые на сервер данные могут содержать XSS, XSRF, инъекции SQL кода и т.д. Рассмотрим что произойдет с создаваемым веб-приложением в этом случае.

Осталось реализовать предварительную проверку на стороне клиента для одного свойства – Login. Её особенность в необходимости осуществлять запрос на сервер при каждом изменении пользователем значения в соответствующем поле формы ввода. Можно конечно разработать необходимый функционал самостоятельно и, по сути, заново изобрести колесо. Или воспользоваться возможностями ASP.NET MVC 3.

Было бы странно, если типовые адаптеры пришлось бы создавать бы для каждого правила. Поэтому в ядре ASP.NET MVC 3 уже содержатся варианты для них. Давайте рассмотрим их.

В начале небольшое отступление. Данный примеры создавались для цикла статей про ASP.NET MVC. Они не вошли в него по разным причинам. Однако возможно кто-то еще работает с сайтами на основе ASP.NET MVC 2 или кому-то может пригодиться пример переопределения атрибута. Поэтому я решил опубликовать их отдельно.Читать дальше...

В прошлой части были возвращены исходные значения для параметров ClientValidationEnabled и UnobtrusiveJavaScriptEnabled. Теперь предварительная проверка условий для стандартных атрибутов производится на стороне клиента. Продолжим начатое и дополним ее аналогами созданных атрибутов.

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