Проверка MVC с использованием аннотаций данных - сценарии, где это не работает, альтернативы?

Question

Таким образом, я использовал аннотации данных для проверки в проекте MVC, и они, похоже, работают в большинстве сценариев.

Вот два примера в моем текущем проекте, где они, кажется, не подходят, и я не уверен, какое место лучше поставить для проверки.

1) У меня есть страница «Присоединиться к лиге», которая содержит форму, в которой зарегистрированный пользователь вводит имя своей команды и нажимает кнопку, чтобы присоединиться к лиге. Когда они отправляют форму, мне нужно убедиться, что у текущего пользователя еще нет команды в лиге. Поэтому в основном необходимо запросить в БД этот идентификатор пользователя и идентификатор лиги, чтобы убедиться, что для пользователя не существует команды. Моя ViewModel не содержит идентификатор пользователя, поскольку он не имеет отношения к представлению.

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

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

Есть идеи?

Answer 1

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

Правила типа «Когда они отправляют форму, мне нужно убедиться, что у текущего пользователя еще нет команды в лиге», звучит как БизнесЛогика, а не проверка входных данных, и вы, возможно, захотите обработать ее по-другому.Эта логика может, например, войти в метод CanSave класса «Пользователь» или что-то подобное - главное, чтобы отделить его от проверки ввода, если вы можете.

Answer 2

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

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

ModelValidatorProviders.Providers.Add (new YourCustomProvider ());

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