Использование двух строго типизированных моделей для одного представления MVC

Question

Я упускаю что-то фундаментальное для принципалов MVC или я схожу с ума?

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

Я бы тогда строго набрал представление, чтобы использовать этот класс.

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

Если я создаю классы для всех представлений, я создаю чертовски много дополнительной работы. Должен ли я создавать строго типизированные партиалы для каждого из них? Что если макет каждый раз отличается?

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

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

Answer 1

Я использую методы расширения ViewData из MvcContrib , которые добавляют поддержку нескольких строго типизированных моделей (если они разных типов). Код для добавления их в ViewData выглядит следующим образом:

User currentUser = GetCurrentUser();
List<Project> projectList = projectRepository.GetRecentProjects(currentUser);
ViewData.Add(user);
ViewData.Add(projectList);

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

User user = ViewData.Get<User>();
List<Project> projectList = ViewData.Get<List<Project>>();

Это удаляет как "волшебные строки", так и приведение типов. Обратите внимание, что это ничего не делает со свойством Model представления.

Answer 2

Создайте ОДИН контейнерный класс для любого объекта в вашей системе и используйте для всех представлений - просто

Объекты с нулевым значением не имеют реальных накладных расходов

Answer 3

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

Неоптимальный, да, но это работает. Надеемся, что это будет решено в будущих версиях фреймворка.