Для проверки ASP.Net MVC 2 нужна еще некоторая мысль с точки зрения шаблонов и использования?
Вот, что к чему. Как большинство людей у меня есть свой объект области, и у меня есть свои модели представления. Я люблю идею использовать модели представления, поскольку она позволяет, чтобы модели были созданы специально для данного контекста представления, не будучи должен изменить мои бизнес-объекты.
Проблема, которую я имею, с проверкой уровня типа, определенной на моем объекте области и получении тех правил клиенту. В этом случае позволяет, говорят, что я использую аннотирования данных для описания правил проверки, когда я перемещаю данные от объекта области до модели представления, модель представления больше не знает, какую проверку это должно заставить интерфейс выполнять (потому что проверка определяется назад на объекте области).
С MVC 2 можно заставить это автоматически выполнять клиент-серверную проверку стороны, на основе правил проверки текущего объекта. Но потому что правила проверки определяются на объекте области а не модели представления, я должен был бы копировать правила проверки о модели представления, чтобы заставить это работать.
Как другие имеют дело с этим типом проблемы? Мои взгляды состоят в том, что помимо отображения данных от объекта области до модели представления, мы также должны отобразиться через правила проверки, но я действительно не видел, что другие говорят об этой проблеме... Brad Wilson недавно говорил об этой проблеме подробно, но действительно не обратился к дублированию правил об объекте области и о моделях представления..., каковы Ваши мысли?
Аплодисменты Anthony
5 ответов
Я использовал для этого:
Создание объектов коллекции (массив информации о размере (словарь, NSNumber высот строк и т.д.) на основе объектов коллекции, которые будут использоваться для табличного представления.
Это делается при обработке данных из локального или удаленного источника.
Я заранее определяю тип и размер шрифта, который будет использоваться при создании объектов коллекции. Можно даже сохранить объекты UIFont или любые пользовательские объекты, используемые для представления содержимого.
Эти объекты коллекции будут использоваться каждый раз, когда я реализую протоколы UITableViewDataSource или UITableViewDelegate для определения размеров экземпляров UITableViewCell и их подчиненных представлений и т.д.
Таким образом можно избежать необходимости подкласса UITableViewCell, чтобы получить свойства различных размеров ее содержимого.
Не используйте абсолютное значение для инициализации кадров. Используйте относительное значение на основе текущей ориентации и границ.
Если мы повернем его в любую ориентацию, просто сделайте механизм изменения размера во время выполнения. Убедитесь, что маска автоответчика установлена правильно.
Вам нужны только высоты, вам не нужны все эти ненужные вещи внутри UITableViewCell для определения высоты строки. Вам может даже не понадобиться ширина, потому что, как я сказал, значение ширины должно быть относительно границ вида.
-121--954707-Многие архитектуры имеют команду «найти первое» (bsr, clz, bfffo, cntlzw и т.д.), которая будет намного быстрее, чем подходы к подсчету битов.
-121--3348364-Атрибуты DataAnnotation предназначены для проверки ввода и предоставления обратной связи пользовательского интерфейса конечному пользователю. Это действительно их единственное предназначение. Я использую различные стратегии проверки для объектов пользовательского интерфейса и бизнес-объектов, поэтому атрибуты проверки DA появляются только на моделях, показываемых пользователю.
Возможно, нам вообще не следует использовать модели представлений? И определить правила проверки для объектов уровня модели ..
{{1 }}Это может быть неуместно, но что, если вы просто перенесли правила/нотации валидации из ваших моделей в ваши ViewModels? В некоторых проектах, в которых я участвовал, мы решили не давать Виду доступа ни к чему, кроме информации, раскрываемой через соответствующую ViewModel. Так как все взаимодействие с данными будет осуществляться через ViewModel, то не будет необходимости иметь валидацию на ваших объектах Модели.
Сопротивление этому аргументу заключается в том, что вы можете легко дублировать определенные правила проверки, так как разные ViewModel могут взаимодействовать с одними и теми же Моделями. В этом случае, возможно, имеет смысл просто объявить вашу Модель как свойство, открытое на вашей ViewModel. Для postbacks, они могли бы принять Модель в качестве своего параметра, позволяя инфраструктуре ModelBinder обрабатывать запросы. В этом случае, если ModelState.IsValid ложный, вы можете просто переназначить свойство на ViewModel перед повторным отображением View.
Я бы порекомендовал перенести аннотации в ViewModel. Это имеет смысл, так как многие Views - это а) результат составления нескольких моделей или б) подмножество данных модели.
Я тоже обдумываю этот вопрос уже некоторое время. Я полностью понимаю ответ Брэда. Однако предположим, что я хочу использовать другую систему проверки, которая подходит для аннотирования как сущностей домена, так и моделей представления.
Единственное решение, которое я могу предложить на бумаге и которое по-прежнему работает с атрибутами, - это создать еще один атрибут, "указывающий" на свойство доменной сущности, которое вы отражаете в модели представления. Вот пример:
// 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, можно было бы расширить для обработки этого нового атрибута и запуска атрибутов проверки свойства класса зависимости, но со значением свойства вашей модели представления. У меня просто не было времени на более детальное рассмотрение этого вопроса.
Есть мысли?
It turns out that AutoMapper may be able to do this for us automagically, which is the best case scenario.
AutoMapper-users: Перенести атрибуты валидации во вью-модель?
http://groups.google.com/group/automapper-users/browse_thread/thread/efa1d551e498311c/db4e7f6c93a77302?lnk=gst&q=validation#db4e7f6c93a77302
Я еще не успел опробовать предложенные там решения, но собираюсь сделать это в ближайшее время.
(Перекрестное сообщение об этом в моем (дублирующем) вопросе).