Привязка модели в модуле привязки модели

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

Пользовательские объекты:

public class Category
{
    public int CategoryId { get; set; }
    public string Name { get; set; }
    public string Status { get; set; }
    public string Description { get; set; }
    public IEnumerable<SubCategory> SubCategories { get; set; }
}

public class SubCategory
{
    public int CategoryId { get; set; }
    public string Name { get; set; }
    public string Description { get; set; }
    public string Status { get; set; }
}

Если моя форма возвращает кучу идентификаторов для подкатегорий, мне нужно бежать в хранилище данных и гидратировать объект подкатегории. Из формы список подкатегорий будет представлен в следующем формате:

<input type="text" name="Name" value="This Category" />

<input type="hidden" name="subcat.Index" value="0" />
<select name="subcat[0].Id">
    <option value="1">Something</option>
    <option value="2">Something else</option>
</select>

<input type="hidden" name="subcat.Index" value="1" />
<select name="subcat[1].Id">
    <option value="1">Something</option>
    <option value="2">Something else</option>
</select>

<input type="hidden" name="subcat.Index" value="2" />
<select name="subcat[2].Id">
    <option value="1">Something</option>
    <option value="2">Something else</option>
</select>

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

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


asp.net-mvc modelbinders modelbinder
person dave    schedule 02.04.2009    source источник

Ответы (2)


arrow_upward
5
arrow_downward

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

Более того, это ненужно. Использование презентационной модели имеет большое количество преимуществ, в том числе:

  • Нет необходимости заносить в белый список поля, которые пользователю разрешено обновлять, поскольку модель представления содержит только эти поля.
  • Привязка модели по умолчанию будет работать для всех сценариев привязки модели, кроме самых сложных. На практике я обнаружил, что мне нужно использовать пользовательское связывание модели только тогда, когда значение, которое видит пользователь, должно быть привязано к какому-либо другому значению условным образом. При использовании модели презентации структура вашей модели презентации должна соответствовать структуре страницы, поэтому вам не нужно использовать пользовательский связыватель модели по структурным причинам.
  • Вы сможете создавать свои представления и контроллеры перед созданием базы данных или модели объекта. Это означает, что вы можете получить согласие клиентов на свой дизайн, прежде чем выполнять большой объем работы по созданию окончательной системы. Это помогает устранять структурные проблемы в модели объекта до того, как они возникнут. Просто создайте модель презентации, которая соответствует странице, которую, по вашему мнению, хочет видеть клиент, создайте общий план страницы, используя вымышленный экземпляр этой модели презентации, и покажите ее клиенту. Если они довольны, вы можете построить модель репозитория/сущности и написать запрос LINQ, чтобы сопоставить ее с вашей моделью представления.

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

person Craig Stuntz    schedule 02.04.2009
comment
Спасибо за ваши комментарии Крейг. Я понимаю вашу точку зрения о представлении, но это означало бы, что объект презентации будет передан непосредственно на сервисный уровень для увлажнения фактического объекта. Это кажется немного громоздким, и я с удовольствием уберу посредника и узнаю, как это сделать. - person dave; 03.04.2009
comment
Из-за этого передумал. Хотя большинство моих представлений могут напрямую связываться с моим классом модели сущности, теперь я вижу, что сложные объекты, вероятно, лучше всего связываются с ViewModel. Последний Стадный кодекс и несколько сообщений К. Скотта Аллена, наконец, склонили его в пользу этого. Спасибо, что упомянули об этом первым, Крейг! - person dave; 23.04.2009
comment
@dave - можете ли вы дать ссылку на те статьи, которые помогли вам решить использовать модели презентаций? - person Maslow; 09.11.2009

arrow_upward
1
arrow_downward

Я бы порекомендовал взглянуть на этот пост Singing Eels, в котором приводится пример другого подход. Используя пример подхода StatefulObjectBinder, можно связать коллекции бизнес-объектов, которые необходимо извлечь из базы данных. Поскольку контроллер реализует IModelBinder, у вас есть доступ к репозиторию, который можно использовать для гидратации необходимых объектов и добавления их в коллекцию объектов.

person ZacharyB    schedule 13.04.2009