Куда должна пойти проверка ASP.NET MVC 2: в классах модели или модели представления?

Question

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

Мой вопрос на самом деле, куда должна идти проверка?Я планировал использовать украшения MetaData - особенность mvc 2.

Но или в модели или в модели представления?Или в обоих местах?

Answer 1

Проверка должна выполняться как минимум в модели представления, потому что это то, что вы получаете в качестве аргумента действия и содержит вводимые пользователем данные. Вы также можете пройти валидацию в модели.

Answer 2

Вы должны поместить валидацию, относящуюся к пользовательскому интерфейсу в ViewModel, и все, что связано с проверкой бизнес-процесса или базы данных в Модели.Они могут перекрываться.

Answer 3

У меня лично есть подтверждение 2 места с использованием DataAnnotations. Моя модель не дошла до моего взгляда в полном объеме. У меня есть отдельные модели для моих видов и я перевожу данные из модели видов в модель. Таким образом, я могу поместить все, что захочу, в свою модель представления и пропустить фрагменты, с которыми я не хочу иметь дело.

Однако я считаю, что у меня есть приложение для Windows и веб-приложение, использующее одну и ту же модель. Таким образом, один и тот же набор правил проверки управляет моделью для всех приложений, и моя модель представления может иметь немного другие правила, если это необходимо. Конечно, это создает «дублирование логики» - ну, логика проверки.

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

Answer 4

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

Answer 5

Модель должна реализовать валидацию, необходимую для обеспечения того, чтобы ее состояние не могло стать недействительным; эта проверка наиболее определенно принадлежит модели. например, класс книги должен гарантировать, что его заголовок должен быть от 1 до 50 символов, его идентификатор должен быть> = 0 и т. д.

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

проверка в представлении должна быть ограничена синтаксическим анализом пользовательского ввода для недействительных данных: анти-xss, инъекция sql, вне диапазона. и т.д.