Хорошее MVC

[Wolsh]

Что лично мне не нравится в событиях от Вью к Контроллеру?
Это вобщем-то отлично, когда ничего кроме типа События не требуется.
Но как только возникает ситуация, когда необходимо передавать данные, весь смысл меняется.
Становятся необходимы особые кастомные классы Событий-контейнеров данных. Эти классы должны знать (то есть иметь с ними жесткую связанность) и Вью и Контроллер. Я уже как-то "наезжал" на такую же проблему с событиями от Модели к Вью, и здесь ситуация ничем не лучше. Разруливать ее с помощью неких "интерфейсов событий" имхо маразм, особенно когда напрягает само количество новых классов-Событий, каждый из которых нужен для поддержки одного единственного действия юзера во Вью/изменения данных в Модели — так к каждому еще и Интерфейс заводить?
Я к тому, что в ситуации неявной жесткой связанности через события говорить об идеалах независимости фигурантов MVC довольно лицемерно, а учитывая сильную физическую/логическую связь между Вью и Контроллером (второй, по сути, придаток Вью), я лично вполне допускаю схему с прямой ссылкой и прямым вызовом методов контроллера из вью-хозяина. "Передать массив" в такой ситуации не потребует ни нового Класса События, ни Интерфейса для него, а связанность, по сути, та же самая. Реальную независимость имеет только Модель, и ей ничто не угрожает.

[Котяра]

Если вместо контроллера использовать PM (Presentation Model)
То именно так там и делается.
http://www.martinfowler.com/eaaDev/P...tionModel.html
http://blogs.adobe.com/paulw/archive...tion_pa_3.html
http://examples.pmwilliams.co.uk/ado...iew/index.html
http://examples.pmwilliams.co.uk/ado...ss-diagram.jpg

[lammer.Ok]

Подскажите и мне в вопросе. При загрузке программы, кто грузит все необходимые картинки и тд. для UI? Например, у меня готовится редактор, и мне необходимо подготовить и загрузить много картинок для тулбара. Кто этим занимается из mvc или эту функцию выполняет совершенно левый класс, какой-нибудь UILoader ?

[Dukobpa3]

Менеджмент ресурсов не входит в задачи модели.

Менеджмент ресурсов так же не входит и в задачи контроллера.

Методом исключения приходим к тому что картинки должны быть во вью(ну и очевидно что она ведь их отображает). А откуда вью их возьмет - уже ваша задача придумать.
И вьюха например сама должна знать что для статуса модели "вкл", она должна отобразить картинку "зеленая_галочка.жпг".
Вью может ссылку на эту галочку взять из отдельной какой-то модели-конфига со словарем урлов по иду или готовую картинку из какой-то фабрики.

[lammer.Ok]

Спасибо, так и предполагал.
Не поможете ещё с вопросом, допустим есть небольшое приложение-конструктор, которое состоит:

1) Главное меню, содержит кнопку, при помощи которой очищается рабочая область.
2) Рабочая область, где можно создавать квадраты залитые цветом.
3) Тулбар, где есть 2 кнопки "создание" и "удаление" квадрата на рабочей области. Когда нажата любая из кнопок курсором можно создать или выбрать и удалить квадрат, кликнув по нему.

Сразу скажу опыта с mvc практически нет. Хочу сделать для начала просто, но относительно грамотно.
Планирую так подать это дело в mvc:

1) При загрузке программы Контроллер создаёт Модель и Вьюшку.
2) Вьюшка подготавливает и создаёт внешний вид программы. Устанавливает событие "клик" на кнопку в главном меню и на все кнопки тулбара.
3) Контроллер ловит "клик", когда пользователь нажал на кнопку и определяет, что клик пришёл, допустим с главного меню(или Модель должна определять это?). Записывает в Модели флажок о том, что можно очищать рабочую область.
4) Модель оповещает Вьюшку о изменении в главном меню.
5) Вьюшка проверяет у Модели этот флажок и очищает рабочую область.

Правильно ли я описал до этого пункта?
Далее не знаю как взаимодействовать тулбару и рабочей области. Как например выбрать инструмент "перетаскивания" и передвинуть квадрат. Одно знаю точно у квадрата должна быть своя модель, вьюшка и контроллер? Не подскажите как поступить?

[Dukobpa3]

Всё верно, но пару комментариев.

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

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

Тут может будет для вас что-то интересное:
рас
два

[lammer.Ok]

Спасибо большое. Оказываете неоценимую помощь. Очень интересный этот mvc)
Ещё пару уточнений:

1) Если мы создаём отдельные вьюхи для тулбара и раб. обл., тогда главная вьюшка лишь строит интрефейс программы и устанавливает обработчики нажатия мыши только на главное меню. То есть главными моделью, контроллером и вьюшкой управляется как бы вся программа через главное меню(создание нового документа, выход из программы и тд. глобальные вещи)?

2) На сколько я понимаю главная вьюшка создаёт дочерние mv(c) для тулбара и р. области. А вьюшка рабочей области создаёт mv(с) для ректангла?

3) Среди контроллеров может быть прямая связь без подписок между собой?

[Dukobpa3]

1) пофиг. У меня напрмиер главная вью - просто иннициализатор контейнеров и основных вьюх.
2) пофиг. Структуры ваших деревьев будут зависеть от ваших пожеланий. Тут предполагается, опять же, подумать
3) лучше не надо, но вцелом как ваша душа желает. Можно например сделать главный контроллер и в нем два дочерних, тогда они будут общаться через главный диспатчами.

[lammer.Ok]

Dukobpa3, большое спасибо за ответы, разобрался на данный момент со своими непонятками.

[lammer.Ok]

Появилась небольшая загвоздка в структуре построения дочерних mv.
В этой теме прочитал, что контроллеры создают контроллеры, модели — модели, а вьюшки — вьюшки. Получается, что главные MVC создают основные mvc всего приложения и хранят ссылки на них? Если к примеру, взять тулбар из моего приложения, в главной модели создаётся дочерняя модель тулбара, в главной вьюшке - дочерняя вьюшка тулбара, а в главном контроллере создастся дочерний контроллер тулбара, который свяжет модель и вьюшку тулбара, запросив ссылки на них через родительские MV, типа Model.models.toolbar? В этом собственно и вопрос, правильно ли я понимаю?