Хорошее MVC

[fish_r]

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

[etc]

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

[incvizitor]

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

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

А каким образом лучше организовать получение прототипов из основной модели? И еще, как лучще всего получать их в дочерних моделях?

[etc]

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

А каким образом лучше организовать получение прототипов из основной модели? И еще, как лучще всего получать их в дочерних моделях?

Реализовать промежуточный класс с ленивым геттером основной модели. Так называемый ассет основной модели. Всё, кто в неё попадает, может получить на неё ссылку. Ну а оттуда уже к коллекции прототипов и т. д.

[Crazy]

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

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

[etc]

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

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

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

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

[Crazy]

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

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

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

[etc]

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

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

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

[Dukobpa3]

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

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

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

[etc]

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