Первые шаги в MVC

[Wolsh]

А я вижу. При такой схеме получается...

А при твоей в эту схему добавляется ЕЩЕ ОДНО звено — еще и обратный контроллер. Такое бывает удобно в ОЧЕНЬ сложных крутых проектах, в которых Вью и Модель изначально разрабатывались совершенно независимо и "не ради одной цели" — тогда жизненно необходим "переводчик" между ними. Фишка, правда, в том, что нет особой разницы в трудозатратах — переписать что-то во Вью, чтобы она стала понимать "чужую" Модель, или написать контроллер. Ну, может чуть удобней тестить и настраивать.

1) Нафига тут тогда вообще котроллер?

Потому что Вью не имеет права приказывать Модели. С помощью контроллера Вы регулируете ее права и определяете качество реакции Модели, отсеивая "мусор", распределяя события и данные от Вью по разным ответственным блокам Модели — переводите с языка событий вьюхи на язык операций с данными Модели. Вьюха не имеет доступа к операциям, логике. Она может получать данные, хоть по "вашей", хоть по классической схеме.

А наиболее чистая схема - это когда вьюшка не подписывается ни на какие события модели

Вы не правы. Возможно, Вы просто привыкли к какому-то фреймворку, использующему такую схему. Это грязный фреймворк))) Возможно, в него ввели обратный контроллер ради тех случаев "крутизны", ведь фреймворк должен быть крутым и давать Вам все ВОЗМОЖНОСТИ. Но возможности — вовсе не обязательности. И не надо запутывать новичков. Если такой контроллер понадобится — они придумают как его включить в схему.

[LifeIsRhythm]

Ответьте мне на вопрос: зачем при этой схеме вьюшке иметь ссылку на модель?

Чтобы подписаться на событие модели и тянуть из неё данные, которые позволены интерфейсом.

[2misha]

Я ври все размышляю ... если надо увеличить переменную не на 50, а на определенную переменную из Вьюва. То есть создам во Вьюве поле ввода и надо чтоб в Модели переменная увеличивалась на введенную в это поле величину, то как эту величину передавать в Контроллер?

[LifeIsRhythm]

Прежде всего, нужно определить место дислокации этой переменной, так-как не всегда, поначалу, это удается сделать правильно. Для примера объясню на индикаторах жизни и индикаторе энергии -
С каждым нанесенным ударом убавляется энергия, значение которой, нужно и вью ( нужно же показывать пользователю сколько энергии осталось ) и модели ( так-как сила удара, это данные модели, а раз показатель энергии сказывается на силу удара, то и значение этой самой энергии нужны в модели ).
И теперь рассмотрим значение жизни - промежуточные значения жизни ненужны в модели, так-как 100% или 50% или даже 1% здоровья на состояние игры, а значит и модели не сказывается. То есть, промежуточные значения нужны только вью, чтобы показывать индикатор жизни. Но когда значение жизни станет равным нулю, то да, об этом уже нужно уведомить модель, так-как это означает какое-то изменение во всей игре.
А передавать значения из вью можно вместе с событиями.

[in4core]

Потому что Вью не имеет права приказывать Модели. С помощью контроллера Вы регулируете ее права и определяете качество реакции Модели, отсеивая "мусор", распределяя события и данные от Вью по разным ответственным блокам Модели — переводите с языка событий вьюхи на язык операций с данными Модели. Вьюха не имеет доступа к операциям, логике. Она может получать данные, хоть по "вашей", хоть по классической схеме.

весело... Костя прав в одном, а Wolsh не прав в другом.
Мало ли , что написано в книжке, что вью НЕ имеет права дергать модель и т.п., но если есть ТАКАЯ возможность , почему ей пренебрегать? В том то и смысл МВС - разделить логику от представления, а так получается в уме разделили, а на практике даем возможность.
Самым адекватным решением уже принять то, что мвс - многолик. И закрыть на этом тему. Ибо этот извечный холивар - может вью дергать модель или нет, уже зарос мхом.
Хочешь - дергай, только это уже будет свой паттерн , а не мвс, хочешь не давай ссылку модели во вью - тоже будет не МВС ( по сути ) , а хочешь занимайся классической триадой.

[caseyryan]

И не надо запутывать новичков.

Не я их запутываю. А вот такие кривые "mvc", в котором они потом тонут. Это не mvc, а бардак. Лучше вообще его не использовать, чем делать из него такое извращение. Я думаю тут мало найдется тех, кто поспорит с утверждением о том, что без mvc можно обойтись.

В принципе, если следовать вашей логике, то можно реально обойтись без контроллера. Что плохого в том, что вью вызовет у модели метод doSomething(), а модель что-то там сделает (прошу заметить, сама сделает, хоть и по просьбе вью) и вью через getSomething() заберет результат? Логично ведь? Зачем городить контроллер, ведь такой вариант еще менее ресурсозатратен.

Вывод: не надо делать из mvc кашу. Используйте нормальный mvc, в котором у вью нет никаких ссылок на модель, либо используйте это пародию, но не называйте это mvc

[LifeIsRhythm]

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

И ещё к Вам вопрос - если делать кнопку, то сам класс Button будет DisplayObjectContainer, в котором хранятся ссылки на скины-стейты... А почему так, если можно рисовать прям в самом DisplayObjectContainer?

Самым адекватным решением уже принять то, что мвс - многолик. И закрыть на этом тему.

А мне после вывода в предыдущем посту наоборот хочется спросить, делает так кто-нибудь ещё или нет!

[in4core]

А мне после вывода в предыдущем посту наоборот хочется спросить, делает так кто-нибудь ещё или нет!

Врядли много кто, так как это много сущностей, что замедляет скорость разработки.
То, что предлагает Костя, это некая модификация MVP. Вью шлет событие в контроллер, контроллер дергает модель, далее контроллер запускает или же просто передает параметры во вью. Это тоже не MVC - это MVP. не путайте

[caseyryan]

что хочется попросить дать ссылку на описываемый Вами вариант.

Как бы google.ru. Я это изучал несколько лет назад, и ссылок не храню. Но та же википедия вполне разумно раскрывает тему mvc.

И ещё к Вам вопрос - если делать кнопку, то сам класс Button будет DisplayObjectContainer, в котором хранятся ссылки на скины-стейты... А почему так, если можно рисовать прям в самом DisplayObjectContainer?

А как это противоречит всему вышесказанному? По-моему вполне логично, что вью содержит ссылки на свои скины.
п.с. DisplayObjectContainer нельзя расширить напрямую и использовать его тоже нельзя. То есть своя кнопка будет в любом случае Sprite или MovieClip, это так, к слову

[LifeIsRhythm]

Как бы google.ru. Я это изучал несколько лет назад, и ссылок не храню. Но та же википедия вполне разумно раскрывает тему mvc.

Тогда у меня для Вас "пренеприятнейшая новость" - Вы несколько лет делали не пойми что!



Картина взята из wiki, ссылка прилагается в конце поста.

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

Model-View-Controller - wikipedia.org

Добавлено через 23 минуты
А про кнопку... естественно я знаю, что наследоваться от док нельзя, но я это сказал к тому,
что имея возможности рисовать в самой кнопки, мы разделяем ответственность и используем композицию.
Так же и с вью, хоть она ссылку и имеет, но имеет на интерфейс с геттерами, и даже если бы и прямую ссылку, то куда денется правило об разделении ответственности. Да, можно и из вью модель менять, можно и без контроллера и без модели и писать в кадрах. Ведь это тоже возможно, можно и язык отрезать, кому на что фантазии хватает...

Добавлено через 38 минут
И хочется сказать ТС, Вы упомянули, что читаете книгу про MVC... Если это книга про as3 MVC, то вот саму главу об MVC можно бегло пробежать, чтобы увидеть на её примере работу других паттернов, так-как MVC, это совокупность паттернов. И так же хочется сказать, что эти все паттерны уже реализованы на нативном уровне, но это все равно не освобождает Вас от прочтения всей книги. Целиком!

Добавлено через 40 минут
Вот об MVC, читать все и так же все по всем ссылкам.

Добавлено через 45 минут
И Спасибо Psycho Tiger'у!!!