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