Здравствуйте, Козьма Прутков, Вы писали:

КП>Насколько я понимаю классическое описание MVC, то по современным меркам роль контроллера выполняет само представление (ему ведь в бизнес-приложениях не надо рисовать хитрые картинки, все это делает ОС и библиотека). А обработчики событий контролов — вот основная часть классического представления о контроллере, а в данный момент они располагаются как раз в "формочках", классах code-behind и т.п. А контроллер, в моем понимании на данный момент, выполняет роль координатора некоторого процесса (например, сценария использования), то есть управляет последовательностью показа форм и моментами, например, сохранения модели в БД. Правда, там по науке контроллеров разных — пруд пруди
КП>По логике вещей, вью должен иметь возможность передать контроллеру, его вызвавшему, команды пользователя. Соответственно, контроллер получает откуда-то команду запустить процесс, показывает первый вью. На нем пользователь выполняет какие-то действия и команды, которые представление (выборочно, естественно) передает контроллеру. По факту выполнения какой-то команды контроллер принимает решение предпринять какие-то действия (например, закрыть (или не закрывать) этот вью и показать следующий).
КП>По большому счету нет тут никакого паттерна. Как вариант, класс реализующий некоторое количесткво интерфейсов (по количеству вью им обслуживаемых) или имеющий некий обобщенный (соответственно, мало типизированный) интерфейс.
КП>Ничего другого в голову не лезет.
КП>Если не прав — поправьте пока не поздно

Но где должен создаваться объект контроллер и модель вместе с ним
Допустим если разработка ведется под Win на C++