MVC в C #: модель - отношение контроллера

Question

Обычно у меня есть один контроллер и одна модель. Есть ли disgn-pattern для того, чтобы иметь 1 View с несколькими контроллерами и несколькими моделями. Где у самого контроллера тоже может быть несколько моделей?

Некоторые ссылки на связанные шаблоны были бы хорошими.

Answer 1

Обычно контроллер имеет только одну модель. Тем не менее, вы можете создать составную модель, которая сама имеет несколько моделей.

class CompositeModel
{
 private ModelA modela;
 private ModelB modelb;
}

А затем ваш контроллер набрал это.

Но если вы в конце концов не знаете, что делаете, это план, который закончится только слезами.

Но если вам удастся избежать паттерна Божьей Модели, он может быть очень мощным.

Answer 2

Существуют и другие методы, разработанные начиная с MVC, а именно Presenter Model View. Здесь на сайте Мартина Фаулера - хороший обзор этих паттернов.

Мое собственное приложение использует пассивное представление, поскольку оно позволяет нам срывать пользовательский интерфейс и легко заменять другое. Это преимущество для нас, поскольку наше программное обеспечение представляет собой приложение CAD / CAM, предназначенное для использования с различными станками для резки металла.

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

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

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

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

Иерархия выглядит следующим образом.

• Интерфейсы реализации форм Forms
• Реализация интерфейсов интерфейса пользователя и взаимодействует с формами через форму Интерфейсы
• Команда взаимодействует с режимом и UI через интерфейсы UI.
• Интерфейсы пользовательского интерфейса
• Модель

Answer 3

Я бы порекомендовал больше изучать MVC.

Answer 4

Это действительно имеет смысл, только если у вас есть иерархия моделей (наследование), в которой представление отображает общие свойства различных дочерних моделей. Концептуально это может сработать, но с практической точки зрения я не вижу, чтобы это случалось очень часто. В моем коде единственное место, где я подхожу к чему-то подобному, это поле «Контакт». У меня есть модель пользователя, которая имеет собственный контакт и аварийный контакт. Оба контакта относятся к одному и тому же типу, причем дифференциатором является то, являются ли отношения «я» или что-то еще. У меня есть одно представление для создания этих контактов, и это представление отображается двумя различными действиями на одном контроллере - CreateContactInformation и CreateEmergencyContact. Но даже в этом случае оба используют одну и ту же модель - Контакт. Я мог бы выбрать подкласс модели, но на самом деле не было достаточно различий, чтобы оправдать эту сложность.

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