MVC: грамотная архитектура проекта

[Babylon]

Я не использую понятие медиатор, у меня вью это иерархическая структура, состоящая из контейнеров, которые заполняются виджетами. Виджет ничем не заполняется - это терминальный визуальный элемент
Команда формирует XPath запрос, который вырезает нужную структуру из иерархии видов. Для этого нужен XML.

[Dukobpa3]

терминальный

Терминал? Это который bash, cmd, powershell?

[Psycho Tiger]

Сообщение от Dukobpa3

Терминал? Это который bash, cmd, powershell?

Это по научному так называют "конечный".

Команда формирует XPath запрос, который вырезает нужную структуру из иерархии видов. Для этого нужен XML.

Решение приятное и, возможно, единственное, если в фреймворк добавлять e2e тестирование.
Но зачем тащить с собой XML? Чтобы перевозить апельсины нужна ёмкость – бочки?

[Wolsh]

Иерархию, конечно, можно и на Обжектах строить)) Однако у них то нет такой плюшки как XPath/e4x.

[Dukobpa3]

Ябпосмотрел.
А то смущает меня прозрачная вью, вывернутая наизнанку по отношению к системе.
Но, в целом, теперь понятно что такое XML-MVC. Если еще и модели зеркальное дерево имеют - то вполне удобно должно быть.

Добавлено через 12 минут
А, ну да.
Еще и новое слово выучил

Это по научному так называют "конечный".

Вот как хорошо что не иссякли темы про мвц
В них всесторонне развиваешься

[Wolsh]

Dukobpa3, а можно поконкретней про медиаторы?))
"для всей системы Вью это медиатор" — для какой системы? Для кучки растерявшихся контроллеров?
Можно ли [выдумать] какой-то простой пример, типа "есть два таких-то Вью, есть два контроллера. И вот возникает такая ситуация /*описание ситуации*/. Тогда мы вводим медиатор, который регистрирует контроллеры и вьюхи, и /*описание действий медиатора*/.
Желательно, чтоб было понятно не только мне, но и другим всесторонне развивающимся))

[Dukobpa3]

Сообщение от Wolsh

для какой системы?

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

А про медиаторы я тут только что много чего-то написал, но так написал что и сам бы не понял. Решил не отправлять. Я подумаю как сформулировать и позже повторный заход сделаю.

Добавлено через 22 минуты
А вообще меня уже конкретно припарил мвц.
Изначально мне нравилось потому что у меня были контроллеры, которые инитят свои модели и свои вьюхи. Получалось модуль - это по сути контроллер, а что там внутри него - уже мало кого волнует, он там сам в себе рулил делами с моделями и вью.

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

Так из контроллера ушла инициализация вьюх и моделей. Получилось три разных плоскости для моделей вью и контроллеров, внутри каждой из плоскостей все объекты одноуровневые (как в РЛ). Но я продолжал воспринимать понятие модуля как контроллер. Хотя это уже больше на граф похожу из трех видов узлов.

Теперь вроде и четкого мвц не осталось, вроде и удобнее чем было. И грубо говоря на всю систему осталась одна вью, одна модель и один контроллер (пусть они и выглядят как коллекция из структур а не одна структура, но мы ведь в большинстве случаев можем на это забить). Разделение ролей между вью, моделями и контроллерами четкое. Это круто, но это уже не тот мвц с которого всё начиналось.

И теперь уже мысли может нафиг это надо и проще ведь можно.

Чувствую скоро забью на все паттерны и пойду функциональщину на петоне клепать.

Добавлено через 2 часа 46 минут
Про медиатор я не знаю как объяснить
Я могу процитировать гофов или еще кого.
Но если:

Сообщение от Wolsh

когда читаешь (у тех же GoF, например), теоретически все понятно.

То к гофам добавить особо нечего.
На практике медиатор не есть необходимым условием, ровно как и все остальные паттерны, как и любые другие задачи - те которые решает медиатор, можно решить иначе.

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

Изометрия:
С изометрией:
Контроллер не знает что у меня есть вью террана(у которой внутри еще тайлы), вью города(у которой внутри здания), вью жителей, дорожного траффика, неба, партиклов.
Контроллер видит мой медиатор города и всё.
Кроме того. Медиатор например слушает клики по зданиям из вью города. Оборачивает в нечто свое, и в контроллер уже посылает более понятную для контроллера информацию.

Да, это можо сделать и корневой вью, в которой ветками будут все эти вью. Но сам по себе медиатор технически не есть визуальным объектом. Это композиция визуальных объектов. Хотя с точки зрения контроллера он и выглядит как вью. Поэтому вот он выделен как отдельная сущность.

Второй пример который я приводил - медиатор попапов.
В этом случае контроллер вообще не вкурсе сколько в нашей программе попапов и что они умеют.
Контроллер умеет понимать несколько сообщений из медиатора: купить что-то, например, или открыть какое-то другое окно.
Про открытие/закрытие попапа контроллер вообще не догадывается. Он просто видит медиатор, и медиатор для него всегда открыт (ну или можно его закрывать, это уже не суть важно).
Опять же. Визуал у нас в попапах. А медиатор просто предоставляет апи аналогичное вьюхе. Но сам по себе не есть вьюхой. Это композиция из всех входящих в него попапов.

Третий пример банально любой компонент.
У нас есть кнопка.
Рисованная, визуальная, кликабельная.
Мы можем контроллером подписаться на эту кнопку, но лучше обернуть ее во что-то и саму логику нажатий инкапсулировать там. Вот это что-то и будет медиатором. (Но в таком исполнении медиаторы не очень люблю и считаю оверхедом, так как можно эту логику инкапуслировать во вью кнопки).
С таким взглядом на медиаторы мы еще более отделяем логику от представления.
У нас получается совсем простое представление, которое даже правильно отрисоваться не умеет, которое даже модель слушать не умеет. Это просто скин. А вокруг скина медиатор, который подписан на модель, и на который подписан контроллер.

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

[Psycho Tiger]

[Offtopic]

Чувствую скоро забью на все паттерны и пойду функциональщину на петоне клепать.

Я так и сделал. (только Ruby/CoffeScript, who cares?) Чувствую себя счастливее. Расстраиваюсь, если всю мою мысль не получается написать одной элегантной строчкой кода.

В них всесторонне развиваешься

Это ещё что! Например, в сетевых кабелях летают электроны (или что там летает): есть электрон – получаем единичку, нету – получаем нулик. Это не секрет, но есть проблема: когда электрон доходит до какой-нибудь точки – это может быть его конечная точка или даже ретранслятор – он отражается и летит в другом направлении. Это проблема. Поэтому на концы ставят специальные штуки, которые гасят сигнал и этого не происходит. Так о чем это я: знаешь как эти штуки называются? Терминаторы

[Dukobpa3]

Главное что нужно понять:
Медиатор НЕ ВИЗУАЛЬНЫЙ ОБЪЕКТ.
Но с точки зрения контроллера ведет себя как вью.

И вот если вам нужен такой враппер над вашей или вашими вью - это будет медиатор.

[alatar]

Wolsh, если в двух словах, то медиатор это контроллер вида. Его задача передать виду модель, слушать от вида события и передать их куда следует. При этом вид ничего не знает о том как устроено приложение.