asp.net mvc - строго типизированные помощники - должен ли объект привязки рендеринга быть таким же, как объект публикации?

Question

я вижу, что asp.net mvc 2 сильно помог мне с типизацией, и, глядя изначально на то, как это работает, я думаю, что, возможно, я делаю что-то не так в asp.net mvc 1 с точки зрения привязки данных для визуализации представления и отправки обратноконтроллер.

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

в пути вдля рендеринга моя модель представления может выглядеть следующим образом:

 public class PersonViewModel
 {
      public int Age;
      public string FIrst;
      public JobCategory[] JobCategories;
      public Sport[] Sports;
      public int NumberOfChildren;

 }

, в этом случае jobCategories и Sports будет использоваться для заполнения выпадающего списка. NumberOfchildren будет просто вставлен html, и я не хочу, чтобы он редактировался.Когда я хочу опубликовать, я хочу передать только тонкий объект только с опубликованными свойствами, поэтому у меня есть другой объект

  public class PersonUpdater
 {
      public int Age;
      public string FIrst;
      public int JobCategoryId;
 }

, это единственные свойства, которые мне нужно передать обратно, чтобы мой контроллер выглядел какthis:

 public ActionResult Update(PersonUpdater personUpdater)
 {
      _repository.UpdateModel(personUpdater). 
 }

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

http://weblogs.asp.net/scottgu/archive/2010/01/10/asp-net-mvc-2-strongly-typed-html-helpers.aspx

есть мысли?

Answer 1

Реальная проблема заключается в том, что текущий принятый подход игнорирует SRP для моделей просмотра немного - форма редактирования действует как ввод и вывод одновременно.

Люди еще не приняли деление view model на, как я их называю, input view model и output view model (для многих - даже создание слоя view model - это слишком много). Поэтому - Mvc2 в настоящее время не имеет поддержки для этого (у вас не должно быть строго типизированного представления, которое не является вводом и выводом одновременно), главным образом из-за неопределенности и отсутствия общепринятых подходов.

Но я действительно думаю, что есть преимущество (хорошо ... это на самом деле компромисс) в углублении и разделении view model на 2 из них. И я не удивлюсь, если эта идея будет развиваться и в конечном итоге станет широко принятой.

На самом деле - у нынешнего подхода даже есть имя - Принцип грома . И если такие парни, как Джереми Д. Миллер, говорят, что это правильно, сообщество не будет беспокоиться и не будет искать ничего другого.

---

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

Answer 2

Просто глядя на вашу конкретную ситуацию, мне приходят в голову следующие моменты.

1) Две модели действительно очень похожи 2) Если вы добавите «MiddleName», вы должны добавить его в двух местах 3) Когда вы говорите «Я хочу передать только тонкий объект» - фактический POST будет содержать одинаковое количество данных, будь то привязка к исходной модели или новая (она будет содержать пару ключ-значение для каждого пользовательский ввод в форме) 4) Вы исключаете возможность отображения данных на странице «сохранено нормально» или «что-то не так», поскольку она не является частью модели

По этим причинам я бы рекомендовал использовать ту же модель для GET и POST действия.

Answer 3

Я использую отдельные модели представления для ввода [GET] и вывода [POST], если только эти две модели не идентичны. ИМХО, этот подход более понятен, проще в обслуживании и более четко выражает, какие данные будут обновляться при заданном действии контроллера.

С точки зрения LOC существует определенная стоимость, но дополнительный код обычно не логика . В большинстве случаев я не чувствую, что дублирование некоторых автоматических свойств на двух объектах нарушает принцип СУХОЙ, и я думаю, что цена оправдана для следования SRP.

Другая цена, как вы заметили, заключается в том, что встроенные строго типизированные помощники работают не так хорошо. Задумывались ли вы о том, чтобы написать своих собственных помощников, поддерживающих ваш шаблон? Например, вы можете перегрузить один из существующих помощников, чтобы вы могли указать как source (например, свойство модели ввода), так и destination (например, имя формы поле, которое публикуется в выходной модели).

Answer 4

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

Answer 5

Я бы посоветовал сделать это проще, просто используя один объект для GET и POST. Поддерживаемость кода здесь гораздо важнее / ценнее, чем сохранение нескольких байтов для действия обновления.

Арнис дает хорошие аргументы в отношении SRP и других шаблонов проектирования, но предполагается, что петтерны должны быть адаптированы. Если бы я был тобой, я бы использовал помощь, созданную фреймворком mvc: используй типизированные помощники; используйте типизированные объекты model / viewmodel для GET / POST и, если вам нужно более сложное связывание, создайте пользовательское связующее.

Держите код легким, и ваше приложение останется замечательным.

Answer 6

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

Меньшее связывание не означает, что меньше данных отправляется обратно на сервер.Все входные элементы в форме будут переданы, вы просто не увидите их как дискретные, строго типизированные, «автоматические» параметры.Если вы действительно хотите уменьшить объем публикуемых данных, вы должны ограничить элементы ввода внутри конкретной формы, которую вы публикуете.В конце концов, MVC все еще является HTTP ...

Answer 7

Вы можете указать, к какому свойству вы обращаетесь в помощнике со строгой типизацией, ищите перегрузку с 3 параметрами.

Ничего плохого в вашем методе. Строго типизированные представления помогут вам лучше развиваться, поэтому вам не помешает типо.