Хорошее MVC

[etc]

Crazy, для других контроллеров, очевидно.

И да, контрол — это обыкновенный вью, он — не контроллер. И модель ему приходит извне, от того же контроллера, например. Модель же принадлежит контроллеру (основному) и доступна для других контроллеров.

[Crazy]

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

Crazy, для других контроллеров, очевидно.

Если им нужна эта модель -- почему они не получили ее явно, а ходят за ней к некоторому третьему объекту? А если после изменений системы этому третьему объекту эта модель будет не нужна и ее там уберут -- будем всех переписывать?

Откуда такой странный дизайн?

[etc]

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

[Crazy]

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

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

Это называется blob antipattern -- когда систему пронизывают хаотичные связи типа "захотел и взял публичные данные". И внесение изменений в одной части вызывает непредсказуемые эффекты по всей системе.

Я озвучил рекомендуемый способ: при создании контроллера давать ему те модели, которыми он должен пользоваться. Способ, который не создает проблем на ровном месте. Вы предлагаете вместо этого внести хаос в дизайн, но пока совершенно непонятно, что мы получаем взамен. Ну, кроме "ни о чем не надо думать заранее -- все как-нибудь рассосется само".

[etc]

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

Это всё описание вот этой модели.

[Crazy]

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

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

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

Модель у них может и своя, но также доступна по ссылке, как у всех контроллеров.

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

Это всё описание вот этой модели.

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

[etc]

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

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

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

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

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

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

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

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

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

[spirit2]

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

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

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

[Dukobpa3]

3) Событие таймера слушает модель, в себе содержит время в timestamp, например, при изменении шлёт событие. Вьювер ловит и через форматтер выводит время.

У меня обычно один из двух вариантов:
1. таймер в контроллере. По таймеру контроллер пихает в модель неформатированное время. Модель говорит что ее изменили. Вьюха форматирует время так как ей надо.
2. опять же таймер в контроллере. Контроллер пихает Форматированное время в модель. Вюшка просто берет готовую строку и отображает.

Первый вариант правильнее, так как одно и то же самое системное время(число) можно показать по-разному. А это как раз дело вьюхи.

[Crazy]

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

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

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

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