Нужно ли больше проверять ASP.Net MVC 2 с точки зрения шаблонов и использования? - PullRequest
16 голосов
/ 02 февраля 2010

Здесь лежит земля. Как и у большинства людей, у меня есть мой доменный объект, и у меня есть модели представлений. Мне нравится идея использования моделей представлений, поскольку она позволяет создавать модели специально для данного контекста представления без необходимости изменять мои бизнес-объекты.

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

С MVC 2 вы можете заставить его автоматически выполнять проверку на стороне клиента / сервера, основываясь на правилах проверки текущего объекта. Но поскольку правила валидации определены для объекта домена, а не для модели представления, мне придется продублировать правила валидации в модели представления, чтобы заставить это работать.

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

Приветствие Anthony

Ответы [ 5 ]

3 голосов
/ 06 февраля 2010

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

2 голосов
/ 20 февраля 2010

Оказывается, что AutoMapper может сделать это для нас автоматически, что является лучшим сценарием.

Пользователи AutoMapper: перенести атрибуты проверки в модель представления?
http://groups.google.com/group/automapper-users/browse_thread/thread/efa1d551e498311c/db4e7f6c93a77302?lnk=gst&q=validation#db4e7f6c93a77302

У меня не было возможности попробовать предложенные решения, но я собираюсь в ближайшее время.

(Крест также опубликовал это на моем (двойном) вопросе).

2 голосов
/ 02 февраля 2010

Это может быть неуместно, но что, если вы просто переместили свои правила / аннотации валидации из ваших Моделей в ваши ViewModels? В нескольких проектах, в которых я участвовал, мы решили запретить представлению получать доступ к чему-либо, кроме информации, предоставляемой через соответствующую ему модель представления. Поскольку все взаимодействие с данными будет осуществляться через ViewModel, не будет необходимости в проверке ваших объектов Model.

В противовес этому аргументу можно легко дублировать определенные правила проверки, поскольку разные ViewModel могут взаимодействовать с одними и теми же моделями. В этом случае, возможно, имеет смысл просто объявить вашу Модель как свойство, предоставляемое вашей ViewModel. Для обратных передач они могут принять Model в качестве своего параметра, позволяя инфраструктуре ModelBinder обрабатывать запрос. В этом случае, если ModelState.IsValid имеет значение false, вы можете просто переназначить свойство в свою модель представления перед повторным отображением представления.

Я бы порекомендовал перенести ваши аннотации в ваши ViewModels. Это имеет смысл, поскольку многие виды являются a) результатом компоновки нескольких моделей или b) подмножеством данных модели.

0 голосов
/ 18 февраля 2010

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

Единственное решение, которое я могу придумать на бумаге, который все еще работает с атрибутами, - это создать еще один атрибут, который "указывает" на свойство объекта домена, которое вы отражаете в своей модели представления. Вот пример:

// In UI as a view model.
public class UserRegistration {
  [ValidationDependency<Person>(x => x.FirstName)]
  public string FirstName { get; set; }

  [ValidationDependency<Person>(x => x.LastName)]
  public string LastName { get; set; }

  [ValidationDependency<Membership>(x => x.Username)]
  public string Username { get; set; }

  [ValidationDependency<Membership>(x => x.Password)]
  public string Password { get; set; }
}

Платформа, подобная xVal, может быть расширена для обработки этого нового атрибута и запуска атрибутов проверки для свойства класса зависимостей, но со значением свойства вашей модели представления. У меня просто не было времени конкретизировать это.

Есть мысли?

0 голосов
/ 02 февраля 2010

Возможно, мы вообще не должны использовать модели представлений? И определить правила проверки для сущностей слоя модели.

...