Являются ли аннотации данных действительно хорошей идеей для проверки?

Question

Чем больше я узнаю о ASP.NET MVC, тем больше я знакомлюсь с аннотациями данных.
В частности, в MVC они используются для проверки, и это вызывает у меня некоторые опасения.
Самое большое из-за того, что мне нравится, чтобы моя модель была как POCO и как можно более чистой.
Теперь, что если у меня есть эти классы моделей, совместно используемые несколькими проектами в решении (например, веб-интерфейс, настольное приложение, веб-службы)?
В основном я обеспокоен тем, что аннотации, специфичные для моего приложения MVC, могут повлиять на некоторые другие проекты, такие как Dynamic Data и т. Д. У меня уже есть бизнес-объекты, отделенные от модели базы данных (в данном случае LINQ2SQL), поэтому я не беспокоюсь о том, что аннотации влияют на мой DAL, но мне интересно, насколько правомерен мой страх перед другими проектами.

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

Полагаю, проблема была бы решена, если бы я создал отдельные модели для каждого проекта (веб, рабочий стол, веб-сервис и т. Д.), Но это была бы практически прямая копия моей в настоящее время совместно используемой модели. Это правильный путь?
Это оказало бы большое влияние на мое решение (происходит большое сопоставление от одной модели к другой).

Что вы думаете?
Мне бы хотелось услышать, что вы считаете хорошим и плохим использованием аннотаций данных.

Answer 1

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

Но для более сложной проверки (несколько полей, требуется доступ к БД и т. Д.) Я использую шаблон посетителей, описанный в Проверка сущностей с посетителями и методы расширения .

Answer 2

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

IValidatableObject - самый гибкий из всех, что я видел, когда речь шла о написании ваших собственных проверок. Однако это не поможет вашему конкретному примеру наличия единого хранилища, которое будет содержать все ваши объекты. Но не бойся!

IDataErrorInfo - это еще один способ проверки данных, который можно использовать только в вашем приложении MVC, и это не повлияет на другие проекты.

Если класс реализует интерфейс IDataErrorInfo, платформа ASP.NET MVC будет использовать этот интерфейс при создании экземпляра класса. Таким образом, вы можете отделить свою валидацию, используя интерфейс локатора сервиса или что-то подобное.

Однако я считаю IValidatableObject лучшей реализацией.

Answer 3

Лично я нахожу DataAnnotations очень хорошими для проверки MVC ViewModels и размещенного ввода. Я никогда бы никогда не использовал их в своих бизнес-моделях.

Я также стал довольно неравнодушным к атрибутам проверки на основе атрибутов, потому что в Reflection действительно легко обнаружить, где находятся какие атрибуты.

Answer 4

Действительно, действительно хороший вопрос. Тем более, что все блестящие демонстрационные примеры приложений построены вокруг DataAnnotations и обрабатывают всю проверку, потому что это хороший, блестящий пункт продажи. А кому все равно нравится делать валидацию?

Я думаю, что лучший способ взглянуть на это состоит в том, что они должны быть частью более полного решения проверки, как по структурным причинам, которые вы упомянули, так и по их ограничениям - как вы проверяете такие вещи, как «Является ли это имя пользователя уникальным? ?» или "Разрешено ли этому менеджеру назначать эту задачу этому сотруднику?" используя аннотации данных?

Answer 5

Одна из ваших проблем Кажется, что вы хотите сохранить свой код в чистоте.Это то, чего Asp.net MVC добивается великолепно.

То, на что вы должны обратить внимание, - это использование моделей View, которые помогают отделить бизнес-логику от вашей презентации.

Это старая статья, но она объясняет основы: http://geekswithblogs.net/michelotti/archive/2009/10/25/asp.net-mvc-view-model-patterns.aspx

Answer 6

Не думаю, что вам нужно беспокоиться о совместном использовании декорированного домена в нескольких технологиях. DataAnnotations является частью BCL, и вы можете использовать его в WCF, WPF, MVC, веб-формах, назовите его (возможно, даже в Silverlight).

Поскольку DataAnnotations в настоящее время является основной частью BCL, мы можем ожидать, что другие платформы проверки смогут читать эти атрибуты в будущем, как это уже делает Блок приложения проверки библиотеки Enterprise 5.0. Это позволяет позже расширить модель более сложными проверками без необходимости изменения основных правил проверки.

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

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

Answer 7

Не уверен, что DataAnnotations испортят ваши другие проекты, но ожидается, что они будут игнорировать DataAnotations, если вы не создадите несколько классов для их проверки.

Чтобы сохранить POCO как можно более простым, намерение DataAnnotations состоит в том, чтобы хранить метаданные и данные в одном месте (т. Е. Если требуется, чтобы _UnitsInStock всегда был положительным целым числом, каким-то образом это требование связано с определением данных " единиц в ассортименте "и идеально подходит под определение модели). Это также помогает избежать некоторых ошибок, поскольку, независимо от того, где вы используете проверку (в рамках проекта MVC), правила всегда будут одинаковыми (поэтому вы не можете забыть проверить переменную на минимальное значение на странице A, пока вы проверяете это на странице B). Сообщения об ошибках не обязательны, но вы можете использовать их для отображения более дружественного сообщения, и это сообщение об ошибке будет отображаться повсюду.

Это также упрощает автоматизированную проверку сервера и клиента (mvc).

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

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