Andrey on .NET

В прошлой части были рассмотрены основные принципы создания провайдеров метаданных и правил проверки данных в ASP.NET MVC 3. Давайте теперь доработаем создаваемое демонстрационное веб-приложение и создадим класс для конфигурации любой Модели.

Как уже можно было убедиться, информация, необходимая для осуществления проверки данных, не входит в состав класса ModelMetadata. Давайте разберемся где она расположена и как её изменить.

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

В создаваемом примере веб-приложения существуют классы Модели, которые требуют различного подхода для создания метаданных. И если UserProfileModel использует атрибуты DataAnnotations и провайдера по умолчанию, то для PaymentModel его необходимо разработать.

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

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

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

Наверное многие разработчики используют для своей работы 2 или 3 компьютера: рабочие станции в офисе и дома, ноутбук в деловой поездке или путешествии и т. д. И наверное практически у всех установлены различные дополнения для Visual Studio 2010. Возникает вопрос – а как сделать чтобы на всех компьютерах был установлен их одинаковый комплект?

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

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

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