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

Реализация поддержки правил и разработка провайдера конфигурации Модели завершена. Давайте теперь задействуем его в проекте и посмотрим на него в действии.

Завершим разработку провайдера конфигурации создав правила для пользовательских атрибутов.

Разработаем реализации интерфейса IModelValidatorRule для атрибутов проверки данных, используемых в данном демонстрационном проекте.

В данной части разберемся как создать провайдера правил и какие еще классы нам понадобятся для завершения задуманной реализации провайдера конфигураций.

Разработка интерфейса для источников данных обеспечила независимость от их типов. Кроме того, был создан механизм взаимодействия с ними. Теперь создадим реализацию провайдера метаданных модели как часть провайдера её конфигурации.

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

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

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

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

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