Форум Flasher.ru - Продолжение темы про прослойку контроллеров

Форум Flasher.ru (http://www.flasher.ru/forum/index.php)

- ActionScript 3.0 (http://www.flasher.ru/forum/forumdisplay.php?f=83)

- - Продолжение темы про прослойку контроллеров (http://www.flasher.ru/forum/showthread.php?t=185712)

Продолжение темы про прослойку контроллеров

И так, как посоветовал expl - создавать общую модель для контроллеров и через нее общаться с видами этих контроллеров - так и поступили. Второй вариант, по факту особо не отличается , поэтому оставили этот.

После окончания создания архитектуры получилась схема :
вид1 -> контроллер1 -> модель коммуникации -> контроллер2 - > вид2 ( стрелками обозначено передача событий ). Подход оказался максимально избыточным, ибо как мы видим по стрелкам нам нужно продиспатчить аж 4 события, с одинаковыми именами ( чтоб не путаться ). Почему то никто сразу не предположил, что общение между видами может находится более чем на 1 событии, таких событий может быть уйма. И тогда получается, чтобы передать 1 событие от вида1 до вида2 - нам придется создавать 4 события. Если хотябы 10 обращений = 40 событий - конец читабельности архитектуры , полная неразбериха.

Далее я стал анализировать другие возможности приходящие в голову. Например вместо коммуникационной модели, мы могли бы передать в контроллер2 ссылку на вид1 - ну и что? Пускай будет ссылка, по парадигме не запрещено иметь несколько видов под одним контроллером , а у нас даже еще проще - всего лишь ссылка. И тогда мы уменьшаем кол-во событий от 4 до 1. вид1 - > контроллер1 use вид2 ( стрелка передача события ) . Вроде бы вариант очень приятный, но на помостках этого варианта появляется еще один SingleTonBridge . Что это значит - мы создаем ( как было предложено ) - все таки коммуникационную модель . Но создаем ее 1 раз в ините, как синглтон - и далее в каждом виде где это требуется дергая getInstance - легко и непринужденно общаемся между видами.

Хочется спросить у вас товарищи, чем плохи эти 2 подхода, или наоборот это лучшее решение. На данный момент я не вижу проблем насчет синглтона , архитектура читабельна , обмен данными в 1 событие, не наршуается парадигма МВС , как отдельно взятого государства :)

я вам советую посмотреть pureMVC там очень хорошо сделаны Notifiсation'ы между медиатрами и прочими элементами системы, такие вопросы там не возникают.

использовать pureMVC ради Notifiсations не стоит =)

Цитата:

использовать pureMVC ради Notifiсations не стоит =)

Да читал уже сто раз про отзывы от наших форумчан, от Котяры того же, - все говорят - не юзайте пуреМВС - лажа это. Я им верю))) Да и вообще - самописный велосипед приятнее на ощупь.

Jewels - а по факту темы, что скажешь ?

Цитата:

Да читал уже сто раз про отзывы от наших форумчан, от Котяры того же, - все говорят - не юзайте пуреМВС - лажа это. Я им верю))) Да и вообще - самописный велосипед приятнее на ощупь.

Я по своему опыту сталкивался с тем, что обычно приходится говорить не о pureMVC как таковом, а о его конкретных реализациях в конкретных проектах, а они бывают лажовые, а бывают и нет.
Что же касается лажы, я не думаю, что лажу бы портировали на большинство самых распространенных языков. Вот когда ваши "самописные велосипеды" постигнет таже участь, тогда я и прислушаюсь к вашему мнению.

Цитата:

Вот когда ваши "самописные велосипеды" постигнет таже участь, тогда я и прислушаюсь к вашему мнению.

Тут есть простое правило я его тебе расскажу. Есть люди которые занимаются чем то одним профессионально ( как они считают ) , это не обязательно хороший продукт, но он обновляется поддерживается и т.п. , а есть люди которые пишут для себя . Вот смотри - ты написал игру в ВК , выложил ее все смотрят радуются ( неважно какой там кривой код, какая ужасная реализация ) - народу нравится внешне, начинку не видели. Ты ее продвигаешь и т.п. , собственно занимаешься вплотную. Даже матерые программисты - видя это говорят - молодец, - они не видят твоего соурса - но видят конечный продукт. И допустим какой то человек пишет игру для себя ( он не хочет ее продавать , продвигать, просто хочется на память ). - У него при этом отличный код - отличная графика и т.п. - но ее никто не видит.

Вот тебе аналогия с пуреМВС - его показали, его раскрутили - им стали пользоваться ( неважно какой процент, но стали). И таких предложений кучи и кучи. Тот же свй адресс - самоу такой написать - не сложно. Возьмите сделайте какую нить свою библу ( неважно какую - любую, желательно конечно ту которой не так много реализаций ) - выложите на гитхаб , и т.п. Пропиарте в хабре , на пару постов в разных соц сетях и форумах - предъявите свое творчество в комментариях . Увидите - уже через 2-3 месяца - люди будут использовать ваш велосипед - и радоваться ))

ну что ж с такой позицией остается только пожелать удачи, и успешного, не кривого разрешения вопросов поднятых в этой теме. Конечно же ваш велосипед окажется намного лучше pureMVC да и других фреймворков тоже :-)

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

Wolsh вот смотрите

Код AS3:

this._globalView.graphicModel = this._graphicModel;

this._globalView.define();

this._host.addChild(this._globalView);

 

this._hudController.initialize(this._globalView , this._graphicModel , this._playerModel);

this._drumsController.initialize(this._globalView , this._graphicModel );

this._paytableController.initialize(this._globalView , this._graphicModel );

this._linesController.initialize(this._globalView , this._graphicModel );

Как мы видим все дети конечно держаться в GlobalView . Как ты и говоришь, но глобал не знает имен дитей. Что вы предлагаете , каждый раз пробегается циклом по детям и проверять какой из них какой вид, и от этого решать что делать?!
А как вам такой вариант - сделать общий контроллер и в него загнать ссылки на все виды, которые хотят общаться. И теперь при диспатчинге от одного вида, этот общий контроллер будет делать нужную нам котовасию ?

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

Цитата:

Что вы предлагаете , каждый раз пробегается циклом ...

Я предлагаю иметь такой глобалВью, который хоть немного шевелит мозгами по своей теме. Вы же не создаете триаду MVC для каждой кнопки? Ваши кнопки умеют сами в одном классе разобраться со своими состояниями? Им не нужна модель состояний и контроллер мыши? Так почему же Вью не может заниматься такими же внутренними делами отображения? Это все и должно быть в логике Вью, пока не касается данных в Модели. И даже — если касается — возможны ситуации, когда одна Вьюха сообщает модели об изменении, которое вызвала в ней вторая Вьюха. То есть вторая вьюха выступает инициатором действия в первой вьюхе вместо юзера. Вы ищете перемычку между вьюшками. Сначала Модель, теперь Контроллер. Но между вьюшками ЕСТЬ "перемычка" — глобальная Вьюха, которая их насоздавала.
Меня и раньше насторожили Ваши высказывания "контроллер создает вьюху". Не хотелось холивар разжигать, но в классическом MVC контроллер не обязан даже знать ни о какой вьюхе, то есть может вообще не иметь на нее ссылку, поскольку является не более чем инструментом для общения вьюхи с моделью. Ваши же контроллеры — это ТТУК.
p.S. про this'ы я уже высказывался?