DataAnnotations по сравнению с IDataErrorInfo
DataAnnotations по сравнению с IDataErrorInfo
За и против обоих? Преимущества одного по другому? (особенно связанный с MVC)
3 ответа
Поздний вход в обсуждение, так как я не хочу начинать новый вопрос. Я исхожу из того, чтобы определить, как лучше всего применять к проекту ASP.NET MVC среднего размера.
Позвольте мне сначала резюмировать наши варианты: -
1) IDataErrorInfo прост в реализации. Все, что вам нужно, это получить IDataErrorInfo в вашем классе модели. Загвоздка в том, что вы позволяете привязке модели обеспечивать соблюдение ваших бизнес-правил. Модель должна обеспечивать соблюдение бизнес-правил. Другая загвоздка для IDataErrorInfo (и аналогично для DataAnnotations) заключается в том, что (перефразируя из книги Стивена Сандерсона , он не может сообщить о множественных ошибках, относящихся к одному свойству, или множественных ошибках, относящихся к модели всего объекта.
2 ) DataAnnotation для меня - это как проверка схемы (валидация). Это первая проверка, которую должно выполнить ваше приложение. Однако (IMHO) он не подходит для реализации ваших бизнес-правил.
3) Реализуйте свой собственный ModelBinder. Хотя это можно сделать, но если серьезно, то использование ModelBinder заключается в анализе и привязке ваших данных к вашей модели, а не для выполнения сложных валидаций и проверок бизнес-правил. Я бы оставил проверку бизнес-правил для реализации на уровне модели / домена.
4) Сделайте свой собственный - Проверка с помощью уровня обслуживания (см. this .Показанный пример имеет преимущество в том, что он отделен от состояния контроллера и модели с помощью класса интерфейса. Другой вариант - создать соответствующее исключение на уровне модели. Последний вариант полезен, когда вы реализуете уровень обслуживания в отдельном приложении (например, в приложении WCF).
Как вы думаете? Какие из вышеперечисленных вариантов вы использовали (или собираетесь принять) для проекта среднего и большого размера и почему?
Приветствую
Если перейти в раздел «File» > «New» > «New Project»..., а затем нажать (предполагая, что вы используете C #) «Visual C #» в списке слева, вы получите возможность создать проект «Class Library». Можно извлечь весь соответствующий код в один из них, а затем сослаться в «MAINSITE».
Необходимо указать ссылку на него в разделе «Ссылки» проекта MAINSITE и, возможно, потребуется импортировать проект библиотеки с помощью ключевого слова import .
Поставщик услуг Интернета, вероятно, будет передавать информацию DNS-сервера через протокол DHCP (конечно, эту информацию можно переопределить локально на компьютере). Именно так компьютер будет настроен на DNS-серверы для запуска запросов.
CDN работает следующим образом: компании, полагающиеся на доставку содержимого на основе CDN, будут управлять своими доменами через поставщика CDN. Когда поступает запрос на домен D , компьютер связывается со своим настроенным DNS-сервером и направляется в «авторитетный объект» для рассматриваемого домена D . С этого момента DNS-сервер CDN может ответить ответом, который обеспечивает привязку к IP-адресу, «ближайшему» к тому месту, где возник запрос.
Свойство «ближайший» определяется, среди прочего, на основе IP-адреса запрашивающей машины. Тем не менее нетривиально назначать «метрику» на основе этой информации: нет прямой корреляции между «IP-адресом» и «физическим местоположением», жизненно важной информации для осуществления как можно лучшего содержимого для запрашивающих машин.
-121--3894432-Похоже, DataAnnotations получают официальную поддержку в MVC 2.0. Скотт Гатри опубликовал хорошую статью о проверке модели в 2.0 с использованием DataAnnotations. Учитывая, что команда вроде бы возглавила это направление, можно считать, что голосование в ее пользу.
Датананотации легче реализовать и получать непосредственную поддержку в MVC 2.0.
Однако IDATATARRORINFO позволяет сделать более сложную проверку (т. Е. Валидацию, которая порождает несколько свойств и т. Д.).
Эти два могут быть смешаны и использованы вместе, однако. Нет ничего останавливая вас от реализации обе методов.