ModelMetadataProvider переопределяет альтернативу MetadataTypeAttribute

Question

После игры с Asp.Net MVC в течение некоторого времени я решил фактически использовать ее в проекте. Одна из проблем, которые возникли, заключается в том, что на интерфейсном сайте могут быть разные правила валидации для данной модели, чем панель администратора.

Я знаю свойство MetadataType, но поскольку у вас есть несколько контекстов, это не сработает для нас из коробки.

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

Часть этого решения мне не нравится, так что я закончил чтение стека из своего поставщика метаданных собственной модели, чтобы определить, является ли данный вызов привязкой к модели. Это связано с тем, что когда я этого не делал, я бы правильно понял, что «Object не соответствует типу цели» во время вызова TryUpdateModel из контроллера, поскольку связующее устройство модели пыталось использовать свойства типа A для установки значений экземпляру типа B

Является ли чтение стопки вызовов такой плохой идеей для производства? Есть ли способ выборочно копировать поведение MetadataTypeAttribute без использования атрибутов?

Спасибо заранее,

Джон

Answer 1

Это один из тех случаев, когда вы хотите, ASP.NET MVC Team не запечатанный класс - я уверен, что у них были свои причины. Я собирался предложить просто создать свой собственный атрибут, полученный из MetadataTypeAttribute.

Один из способов идти об этом, чтобы взять источник атрибута и написать свой собственный:

http://dotnetinside.com/framework/v4.0.30319/framework/v4.0.30319/System.ComponentModel.DataAnnotations/MetadataTypeAttribute

Хотя, конечно, это делает ваш код менее ремонтопригодны.

Я бы сказал, что, насколько мне известно, вы уже принимаете правильное решение с помощью ModelMetadataProvider в качестве своего решения. Я немного нервничаю из-за того, что вы анализируете стек вызовов, меняете места, перемещаете что-то в область; вы получите мой дрейф, то есть очень легко сломать код с решением о времени сборки, которое не будет найдено до выполнения или вне QA.

Вы не указали, насколько контекст определенно определен, но я бы лично решил, добавив свойство к самому классу с Enum (конечные возможности и временное разбиение времени) со списком возможных контекстов, затем во время разворачивать класс, заполнять его, готовый к исполнению Провайдера, который будет проходить через правильный метаданный тип на основе значения Enum.

Многие способы кожи этой кошки, но что-то, что собирается сломать на сборке, послужит вам лучше всего, ИМХО.

Answer 2

Если вы не используете MVC 6, вы можете найти ModelMetadata Fluent Configuration полезным.

Некоторые полезные примеры использования можно найти here и here.

Что действительно важно, так это то, что это просто код, который полностью находится под вашим контролем.Таким образом, как только у вас есть разные контексты, вы можете определить различные конфигурации, иначе вы можете играть немного сложнее и сделать (набор) разных регистраций для разных контекстов.

Что действительно помогает - это «украшение» (термин, используемый по назначению!) Свойства базового класса, по крайней мере, вам кажется, что вы не делаете этого.

EDIT: модель метаданных не следует путать с WCF RIA Services Contrib.