MVC: грамотная архитектура проекта

[Akopalipsis]

контроллер слушает модель?) Он может быть подписан на события в модели?

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

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

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

Добавлено через 37 секунд
А про эту статью я сто раз читал, что она вроде как не правильная...

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

[AlexCooper]

Akopalipsis какую статью?

[Wolsh]

Akopalipsis, для начала скажите, к какому из фигурантов MVC относится сервис?

[Akopalipsis]

для начала скажите, к какому из фигурантов MVC относится сервис?

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

какую статью?

Вот от сюда хотя бы http://www.flasher.ru/forum/showthre...138349&page=53

[Tails]

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

@Tails
Судя по Вашему примеру с дробовиком, Вы вообще отвергаете мой 2-рой вариант реализации выстрела (модель заявляет о начале выстрела и ожидает известия от контроллера, что вид закончил отображение выстрела). По моему этот вариант дает возможность синхронизировать поведение модели с отображением этого поведения, Но все же меня просто бесит то, что модель ждет разрешения на продолжение деятельности от вида. К тому же такой подход сильно прибавляет в коде: модель расказала виду, он некоторое время это отображает и докладывает контроллеру о завершении, а ток уже командует модели "давай, расказывай дальше". Каждый набор последовательных действий порождает целый вихрь из евентов... Даже если бы это был ТРУ-МВЦ, я бы не стал так делать - просто заворот мозгов!

Конечно вас это бесит, потому-что это вообще "чёрт знает что", как вы до такого только додумались.. Зачем модель должна что-то там синхронизировать с вью? Модель работает сама по себе, она ничего абсолютно не должна знать про то, кто её, как и где нарисует.

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

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

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

В визуализатор может помещаться слушатель пользовательского ввода, который будет регестрировать клики мышкой, ввод с клавиатуры и прочие действия игрока. Затем, слушатель их минимально обрабатывает - (нажата кнопка включения двигателя, нажата кнопка стрельбы) Эти данные считываются контроллером и уже он принимает какие-то конкретные действия. Слушатель помещается во вью только потому, что от-туда ближе всего доступ к устройствам ввода.

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

Кому?

Добавлено через 12 минут
AlexCooper Вы не сочтите мой короткий вопрос - "Кому", за дурной тон. Просто мне уже раз обьясниле, что если контроллер подписан на модель это не mvc..

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

Если более обширный пример - то система игровых триггеров. Игровой триггер - это некоторое действие (контроллер) который активируется по наступлению некоторого события в игре (подписан на модель)

[elder_Nosferatu]

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

Лично мне на ум приходит умная самостоятельная вьюшка, которая принимает от модели текущее количество денег в казне и массив, с количеством элементов, равным количеству башен и каждый элемент обозначает количество заработаных башней денег. Таким образом модель занимается только важной работой (наблюдает за башнями и во время обналички трофеев расказывает кто сколько заработал). Что вид будет делать с этими данными ее не колышет. А вид действует по своему сценарию - сгребает монеты с башни и благодарит ее фразй, потом переходит к следующей. Завтра я передумаю и буду сгребать монеты со всех башен одновременно и это никак не отобразится на модели. Зато модель не знает сколько вся эта сценка должна длиться. И даже если посчитать сколько времени уйдет на сгребание всех монет, то все равно модели не извесно сколько длится звучание благодарственной фразы. По этому ей прийдется глубоко вдохнуть и ждать разрешения выдохнуть кнопку закрытия окна.
В результате мы имеем изящную, но зависимую модель и умный вид, который может легко и без вреда для окружающих менять свое поведение.

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

А теперь очень жду, что мне подскажут, почему мой MVC такой некрасивый, а если он у вссех такой, то почему от него так тащатся?

[Tails]

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

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

Вот до этого абзаца вы рассуждали верно. Вам не нужно засовывать ваши "экраны меню" в модель. Экраны меню - задача исключительно визуализатора. Модель должна лишь предоставлять все необходимые данные: очки, данные вышек, заработанный профит.. Как долго воспроизводить анимаций/звуки и когда игроку показать кнопку "выход" - решает только вьюшка.

[Akopalipsis]

Как долго воспроизводить анимаций/звуки и когда игроку показать кнопку "выход" - решает только вьюшка.

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

[Tails]

Да, нужно уточнить:
В данном примере, мы имеем окошко вьюшки - отображающее статистику пройденного уровня. Это окошко - диспетчер, которое изначально имеет 1 событие - [EventExit]. На это событие подписан контроллер, который ожидает его от окошка.

Получается такая схема: Игра заканчивается, запускается окошко статистики, которое зараза, сразу не показывает кнопку выход! Оно насильно отобразит вам анимацию, проиграет 15 звуков и только после этого появиться кнопка выхода, нажав на которую, вышлется событие [EventExit] и внешний контроллер продолжит выполнение.

Таким образом, в своей локальной зоне - вьюшка сама решает, когда ей показать кнопку, как выслать событие [EventExit] (нажав на кнопку, подождав всю анимацию или т.п.) и выслать ли вообще.

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

И если опять таки модель не будет знать о длительности анимации дробаша, то как она поймет что уже нужно второй выстрел диспатчить?

Дробовик перезаряжается не через анимацию же! У дробовика модели есть переменная - recharge, которая указывает, сколько ещё времени нужно дробовику, что-бы тот перезарядился. Дробовик в моделе выстрелил - вью словила эвент и нарисовала огонь. Что тут не понятного?

[Akopalipsis]

Тогда получается так: юзер убивает последнего монстра и модель узнает из внутреннего события об окончании монстров в хранилище. Она шлет событие "конец". Вью его ловит и проигрывает анимацию о длительности которой модель не обязана знать. Внутри вью как не крути логика есть все равно, но своя внутри-вьшная, считать кол-во частиц, начало конец анимации и т.д. Но её события на все приложение роли не какой не оказывают, даже по окончанию анимации и после принятия внутреннего решения о показе кнопки, при клике она шлёт событие передаваемое контроллером в модель. И модель уже решает - перехожу в главное меню. И это нормально. Но у меня после прочтения вопроса ТС до сих пор остался вопрос без ответа - почему в описанном мной случаи уведомление от вью модели - это нормально, а уведомление, когда модель не знает о времени воспроизведения анимации выстрела - это не нормально...?