Хорошее MVC

[etc]

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

Отлично. Пусть знают, если это им нужно. Зачем, кстати?

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

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

Если у них уже есть нужные им данные -- зачем они лезут в чужую модель? Если в их модели нет нужных им данных -- ее неправильно спроектировали. Нужно исправить, пока не поздно.

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

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

Какое конкретное свойство этого дизайна не позволяет реализовать описанным мной способом, не лазая в чужие модели? BTW, неоправданное использование нестандартных нотаций мягко говоря не способствует коммуникации.

Никакое, можно и так, просто нет смысла настолько абстрагировать контроллеры. Это касается только лишь линков на основной контроллер и основную модель, конкретные данные, как я уже говорил, приходят аргументами.

[Crazy]

Никакое, можно и так, просто нет смысла настолько абстрагировать контроллеры.

Смысл состоит в следовании Law of Demeter для минимизации зависимостей. Однако это возвращает нас к моему вопросу, который был фактически проигнорирован:

Вы предлагаете вместо этого внести хаос в дизайн, но пока совершенно непонятно, что мы получаем взамен.

Если ничто не мешает нам сделать в соответствии с нормальной практикой, то какие же преимущества мы получаем, отказавшись от минимизации зависимостей? Каковы плюсы помимо "я уже сделал именно так"?

[fish_r]

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

[etc]

Crazy, хаоса никакого, просто в 90% случаев контроллеру нужна так или иначе основная модель, для получения прототипов или иной ерунды, поэтому она по умолчанию идёт линком у родительского контроллера и всё тут. Я опираюсь на собственный опыт (а я считаю, что он уже достаточен) и минимизация зависимостей вот как раз в таких случаях — простое помешательство на MVC, выливающиеся в геморрой по передаче 100500 параметров, вот и всё. Да, можно всё сделать по фен-шую, только незачем и никому это не нужно.

[Crazy]

Резюмирую: никаких плюсов мы взамен не получаем.

Спасибо за дискуссию.

[Dukobpa3]

У меня для этих целей есть обычно два синглтона:

1. Для каких-то статичных данных (Это например грузим что-то с сервера пачкой, там базовые настройки системы и в таком духе, и вот реально всем они нужны в той или иной мере)
2. Для динамических (У меня это банально bulkLoader)

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

[etc]

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

Резюмирую: никаких плюсов мы взамен не получаем.

Спасибо за дискуссию.

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

[Crazy]

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

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

Простите, смысл этой меткой фразы прошел мимо моего сознания. Нельзя ли переформулировать?

[etc]

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

Простите, смысл этой меткой фразы прошел мимо моего сознания. Нельзя ли переформулировать?

К сожалению, нет, потому что я уже всё объяснил.

[spirit2]

Не хватает конкретики для понимания. Тему осилил процентов на 90, а также статьи и другие подобные темы.

Несколько вопросов:
1) Модель диспатчит Event.CHANGE и вьюшка сама разбирается, что конкретно поменялось в модели, или модель генерит конкретное событие "яблоки подорожали", а вьюшка уже отображает новую цену?
2) Вьюшка, слушает события от действий юзера, определяет, что нажата кнопка Play и отсылает контроллеру событие "начало просмотра" (как здесь: http://www.flasher.ru/forum/blog.php?b=348), или вьюшка отсылает событие "меня тут где-то нажали", а контроллер по таргету уже определяет, что раз нажата кнопка с id1, а это кнопка Play, и значит пользователь хочет начать просмотр?
3) Есть таймер. Слушается событие TimerEvent.TIMER, по нему преобразуются значения таймера в понятные юзеру минуты/секунды и отображаются на экране. Отображает понятно вьюшка, а кто должен заниматься преобразованием? Контролер в котором создается таймер и слушается же событие меняет вью (минуя модель), модель в которой слушается событие от таймера созданного в контроллере, а потом диспатчится Event.CHANGE при каждом тике таймера, или вьюшка должна сама слушать от контроллера, преобразовывать и отображать (минуя модель)?

В каком случае более правильное классическое MVC или есть еще варианты? =)