50 страниц(, я до 25 дочитал и уже каша в голове, каждый свою ситуацию разбирает, а в начале темы вообще всё не правильно, уточнить хочется раз и навсегда... Да и я тебе плюсиков понаставлю)))

Ну блин. Я понимаю. Я просто тоже не дятел одно и то же долбить))
Дуй в личку если что, там скайп мой тоже есть.

Читал два дня, очень интересно и познавательно, но некоторые моменты я хочу уточнить.
Меня больше всего интересует вот это:
А кто тогда создаёт? И хочется спросить тех кто начинал эту тему - у Вас за время прошедшее с момента написания, поменялось представление или вы остались при своих мнениях?

Контроллеры создают контроллеры, модели — модели, а отображения — отображения.

Модель же и создаёт при десериализации пришедших данных.
Мнение не изменилось.

Zebestov Спасибо! И ещё вопрос - субклассы наследуются от главных классов или не обязательно?
etc Спасибо!

Лично у меня нет "ядра" MVC, контроллеры и модели наследуются от EventDispatcher, отображения — от соответствующего наследника DisplayObject. В моих приложениях MVC — это просто правила построения, никакого "костяка" или фреймворка.

А лично у меня есть ядро, от которого наследуются модель, контроллер и вид. Кроме этого есть глобальный диспатчер, который наследуется от EventDispatcher и работающий с соответствующими ссылками.
Есть Еngine который выполняет команды. Loader который грузит XML со всем: c иерархией видов , параметрами модели, командами, хэндлерами, коллекциями виджетов, сервисов и настроек.
Вид имеет интерфейс с виджетами, модель с сервисами. Все дела.

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

Хочу уточнить вот что - если модель создает модели, вью создаёт вью, как тогда вью узнает о своей модели?

Контроллер передает в конструкторе.

Как вариант, да и впринципе практически всегда конает.
Но вообще вью может быть подписана не на одну модель.

Т.е. модели к примеру:
- профиль игрока
- текущий бой
- статические данные (ссылки на арт, конфиги и прочую муть)

А вью к примеру - магазин. Подписывается и читает профиль плюс статические данные.
Вью боевки - читает профиль и модель боя.

Добавлено через 5 минут
Я после того как инкапсулировал логику в моделях - перестал комплексовать на тему дробления моделей, вплоть до того что могу на весь проект тупо две модели сделать: Статик данные(конфиги игры, цены в магазине, ссылки на ассеты) и динамик данные(то что меняется во время игры, текущее состояние карманов игрока и в таком духе).

Так как у модели всего парочка паблик методов которые что-то могут изменить - то накосячить очень сложно.
А то что одну модель смогут читать все кому не лень - ну и пофиг. Упрощает жизнь.

я вот как тренируюсь - контроллер создаёт модель и передаёт её во вью. Все как по стандарту.
Вью по умолчанию создаёт круг и считывает цвет у модели. В модели через несколько секунд срабатывает таймер, который говорит ей, что нужно создать другую модель, модель квадрата. Она успешно создает модель квадрата и диспатчит вью, что уже можно рисовать квадрат и считывать с него цвет, так как модель квадрата создана. Вью рисует квадрат, но вью квадрата не чего не знает о модели квадрата. Где у меня хромота начинается?

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

Dukobpa3 Спасибо вам за вправку мозга! я что с миниатюрами забыл, что смена модели это куда больше чем цвет)))

Вроде банальный вопрос, но я лучше уточню - кто слушает стайдж, когда по её ресайзу должны меняться данные в модели?

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

На стейдж подписан Мейн. Стартовый класс игры. По изменению размеров стейджа - меняет содержимое конфига.А далее уже все заинтересованные лица подписываются на него(Часто он у меня просто статический класс, так что никто не подписывается, просто знают что в нем всегда актуальная информация).

Dukobpa3 Спасибо! я пока склоняюсь к двум вариантам - либо в контроллере ( так как у него у одного может оказаться ссылка на стейдж ), либо в контроллере сделать статическую ссылку и слушать в модели ( так как все равно по ресайзу происходит перерасчёт в и передается во вью ).
Вариант с конфигом пока не рассматриваю, но точно знаю что придётся, так как фреймворки этого требуют.
оффтоп. если кто то может помочь в вопросе - какое место занимает Старлинг в MVC, жду Вас в этой теме http://www.flasher.ru/forum/showthre...=202824&page=2

Добавлено через 48 часов 11 минут
Перед написанием этого вопроса, прочел ещё раз посты которые формировали моё сознание)))) И нашёл то, что ещё не спрашивалось - контроллер слушает модель?) Он может быть подписан на события в модели?

Может. Но идею это нарушит.

Вправьте мне мысли
Запуск приложения
Main отдает ссылку на отображение контроллеру
Контроллер создаёт модель ( в конструкторе происходят подготовления )
Контроллер создаёт вью и кидает ей ссылку на модель ( в конструкторе вью происходят подготовления )
Контроллер создает контроллерСервис и в конструктор кидает ссылку на модель
Контроллер сервис в конструкторе создает Сервис

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

Сделай хоть как-то, покажи что получилось, тебе укажут ошибки. А демагогия лично меня уже достала чуток.

Akopalipsis - откуда вообще весь этот код? Вы его сами написали? У вас совершенно нет понятия о том, что должно быть и как с этим работать. Попробуйте сначала изучить самый самый, повторюсь САМЫЙ - стандартный MVC - в блогах у Psycho например есть реализация такового. Изучите, попробуйте написать приложение, какое нибудь простое, а потом сами начнете понимать о чем речь и какие проблемы возникают.
Сейчас я вижу После чего обычно направляют читать книги по AS3 и ООП. Дабы не мучать вас догадками почему? Отвечу : $doc ваш это хост, ссылка на root обычно ( main класс ) , который уже добавлен на Stage. Догадались почему второй параметр стейдж это убого?!

Отлично! А теперь дядюшка Артём расскажет, почему ты можешь быть не прав:

Я процитирую:
Вот именно, товарищ in4core, дело в том глядя на абстрактный кусок кода невозможно судить о том, что и зачем. Это может быть загруженная извне флешка, которая ещё не поместилась на экран, но уже жаждущая скушать stage. А может быть MainController чего-то, что и на стейдже никогда не появится. Ну, так сложилось.

Надуманно? Согласен. Но вот что действительно круто: хозяин кода догадался не перегружать контроллер ненужной болмотнёй по дожиданию доступности stage'a, а сразу передал его в конструктор. Это минус несколько строчек в коде контроллера, это повышения читабельности и гибкости, внимая на моё суждение выше. Такие вот мелочи и создают чистоту и элегантность кода.

Передавать ссылки на stage в конструкторе любого класса используемого как части MVC как минимум не логично. В целом представленный код мне не нравится.

Это можно напридумывать, что угодно. Передавать ссылку на стейдж в контроллер - моветон. Тем более нет таких решений, где это может быть нужно, пока хост не добавлен в список. Есть определенная организация кода. Контроллер лишь ждет наступления сеанса, до нужного момента.
Ну вот хоть лоб себе отбей - тру мвсишники передают в главный контроллер ( а здесь он ГЛАВНЫЙ, черт побери ) - только хост, и возможно, именно ВОЗМОЖНО , loaderInfo.parameters - и то это уже лишнее, ибо после создания контроллера, мы передаем хост, у стейджа которого есть нужны нам параметры.

А где можно почитать про критерии тру-мвсишника? Тоже хочу таким стать.

Перефразирую, для непонятливых :) Люди, которые разбираются в данном паттерне и написали не мало приложений, базируясь на нем.

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

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

Ну раз так то чего уж)))
Будем учиться у великих))

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

Столько вопросов и так мало ответов. А оказывается – всё уже задокументировано единичной реализацией.

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

@Psycho Tiger, Так это же in4core и есть. Просто скрывается.

Psycho Tiger - ты полностью отходишь от темы, совершенно начинаешь нести пургу о другой части, не о той, которая стоит в вопросе. Причем тут задача общения с сервером и stage главного контроллера? Что за бред. Ты заработался походу, нефиг тут филосовстовать - тут конкретно поставленный вопрос был, на который есть конкретный ответ.
Ну, а уж если ты хочешь поговорить о сервере, который тут вообще не причем. То общаться с сервером как раз задача контроллеров, а вот каких именно - непонятно в любом случае, но не то, чтобы непонятно, тут нет четкой постановки. У меня например в приложениях с сервером общаются почти все контроллы, главный общается с методами стейтов ( начало игры, конец игры и т.п.) , например, а дочернии контролы общаются с методами, ну например , методами функционирования инвентаря или каких то других мини боксов, к примеру. Но это опять все сугубо личное, у каждого свое. Да , я и сам говорил ни раз, что МВС - тема то философская , тут нет четко поставленной задачи, но в некоторых местах, она все же есть, иначе бы формулировки паттерна не было. Так вот и с главным контроллером - new MainController(host) , new BaseModel(БЕЗ НИЧЕГО), new BaseView(...rest) . Понятно дело, что от концепции всегда можно отойти, придумать свою - именно для этого и создан МВС, но написать например new BaseModel(this._server) - можно сразу руки рубить.

Вопрос был в описании "паттерна MVC".
Когда ты пишешь о том, что паттерн создан для того, чтобы отойти от его концепции – это значит что ты не понимаешь предназначение паттернов.
Когда ты называешь архитектуру паттерном – это значит что любая архитектура у тебя под копирку. Это значит что ты не растёшь над собой.
Когда ты утверждаешь что "общение с сервером задача контроллера" – это значит что ты используешь "толстый контроллер". Всё бы ничего, но твоя формулировка четко отдаёт главным: ты не понимаешь, зачем придумали MVC. Ты используешь его "потому что это круто и все так делают" и держишь в уме заготовленную фразу "ну это типа отделяет отображение от логики".
Но что хуже всего: у тебя нет желания саморазвития. Это выражается в отсутствии взглядов на MVP, MVVM, Model Delegate или даже примитивно похудевший контроллер, который повышает модель из статуса Observable VO в статус действительно модели. И это даже без взгляда на твои недавние топики с вопросами, которые стоило разобрать, ну не знаю, года 2 назад?

Извини если что-то сказал обидное, но я глубоко тобой разочарован.

Лучше бы обсудили имплементацию нескольких интерфейсов у класса Вида или Модели и их взаимодействие с соответствующими proxy классами. PTiger любит абстрактно порассуждать. Не вижу ничего плохого.

Ни в коем случае, я не обижаюсь, ты сказал все верно, я уже давно не развиваюсь в этой сфере, дабы не испытываю большой нужды, у меня четко поставленная концепция разработки программ на МВС, лишнего мне не надо. А вот по поводу - пишу на нем потому что МОДНО - тут не прав, я пишу, потому что это очень УДОБНО, удобнее, пока ничего не встречал, как в плане дописывания модулей, так и в плане быстрой организации любого приложения.
Psycho Tiger. Давай тогда поставим вопрос ребром. ( не знаю как у тебя, у меня программирование это второй заработок , скорее больше хобби ). У меня нет ОГРОМНОГО ( подчеркну это слово, дабы тем не менее всегда узнаешь, что то новое) желания развития дальше в этой сфере
а) Все, что я знаю - достаточно для того, чтобы писать хороший, чистый код, который будет выполнять то, что от него требуется
б) У меня нет ни одного приложения, которое не работает или работает с глюками.
в) У меня стабильная клиентура, которая мной полностью довольна, мне не нужно рыпаться по фриланс сайтам ища работу за копейки.
г) При том, что это мое хобби, так скажем, мой заработок составляет в среднем 3000$ в месяц.
И так, я имею все, что нужно, а так же высокий ЗП, даже по МСК, если считать. О каком саморазвитии мне нужно подумать, скажи мне, студент? Сидеть, читать книжки по паттернам, статьи на форумах англоязычных и т.п., ради лишь того, чтобы сидеть тут с тобой и мерится письками, кто лучше понимает МВС? Ну это просто смешно.
Да несомненно, это может еще и пригодится работая в команде флешеров, но меня данная стезя не привлекает , подстариваться под кого то, соблюдать конвенции принятые только в данном офисе и т.п. - фу и фу. :)
На самом деле ты еще просто молод, вот и прет у тебя юношеский максимализм, типа я круче всех, могу со всеми поспорить и т.п. - ну это не плохо и не хорошо, это в порядке вещей, с возрастом придет осознание, и естественно ты забудешь, о том, как сидеть и пояснять всем , что такое MVP, а что MVVM , у тебя будут слегка другие приоритеты в жизни :) Удачи.
И я думаю далее, лучше помоги человеку, который задал вопрос, дабы тема вроде как не для холивара, а не спорь со мной, все равно не переспоришь)))

Прежде чем начать оправдываться, хочу поблагодарить in4core за его труд!
Если бы не он, то возможно я бы и не получил ответа, на свой глупый вопрос.
Такой "код".. я даже не буду говорить от куда он взялся, лучше его раз и навсегда забыть.
Статью Psycho Tiger я не один раз прочёл, но возможно и вправду что то не допонял. Ещё есть догадка, что меня не понимают из-за того, что я хочу сделать так, как в жизни не когда не делают.

Примерно так.
Контроллер инитит модель и вью.
Вью подписывается на модель.
Контроллер подписывается на вью.
Когда из вью что-то прилетает в контроллер - он может дернуть модель и что-то в ней поменять. А модель в свою очередь собщит об изменении наружу.
Так что всё грубо говоря верно, только кода мало, думаю когда будет больше - появятся еще вопросы.

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

Т.е. именно эту ситуацию лучше было решить без контроллера вообще.
В модели лежит словарь:
А вью при клике просто лезет в модель и смотрит нужный цвет.

//==========================

Второй вариант.

Так как сделал ты. Но в модели есть переменная : currentColor
И в методе в котором у тебя свитч и диспатч пачки событий наружу - просто установка значения в эту переменную, и диспатч ОДНОГО события CHANGE вконце.

Вью получает событие, и рисует model.currentColor

//====================

Короче идея в том что в модели не только логика. Но и данные.
Т.е. логика которая не меняет данных - модели не очень нужна. Хотя туда можно добавить какие-то методы типа: