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

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

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

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

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

Ответ 1

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

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

Ответ 2

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

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

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

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

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

Ответ 3

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

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

Ответ 4

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

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

Ответ 5

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

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

Также очень легко внедрить автоматическую проверку сервера и клиента (mvc).

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

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

Ответ 6

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

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

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

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

Ответ 7

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

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

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