Пара философских вопросов о MVC

[Хомяк]

Ну вот. Люблю, не люблю. Так бы и сказали. И вообще, что за мысль писать сервер на PHP? Теоретически можно на нем и операционную систему написать и кому это в голову приходит?

Оф топ. Искал одну цитату etc по этому поводу, не нашёл. За то нашёл это. Что богами не рождаются?

[JackFromChaos]

Сообщение от Хомяк

Ну вот. Люблю, не люблю. Так бы и сказали. И вообще, что за мысль писать сервер на PHP? Теоретически можно на нем и операционную систему написать и кому это в голову приходит?

Ну вот приходит... Причем раньше я думал что эти страдает в основном постсоветское пространство, ан нет... Вели мы перегоры с одним крупным американским издателе на предмет заказа на социальную игру... Ну так одно из требований было - сервер на php. Правда с заказом не сложилось. А вот заказик для vkontakte/мой мир/однокласники для наших делали... И тоже на php.

Есть своя игра, у нас есть, так там сервак на шарпах... Я правда в этом проекте не участвовал, но с архитектурой там, на сколько я знаю... так себе... http://vkontakte.ru/app2007787_10066149?ref=1
Но это уже скорее результат подхода... Когда game-design меняется несколько раз координально на протяжении разработки на 180 градусов, а диз док отсутсвует как понятие... Сложно ожидать, что программисты, сделают все красиво.... Как говорится первый социальный блин

[Хомяк]

попробовал загрузить, мин. 10 что то грузила, выдала приветствие, что то попросила нажать, потом это:

	Error #2044: Необработанный IOErrorEvent:. text=Error #2032: Ошибка потока.
at eo.sound::Sounds/getByName()
at eo.sound::Sounds/play_private()
at eo.sound::Sounds/play()
at eo.game::EOGame/play_music()
at eo.game::EOGame/initialize()
at eo.game::MainScreenGame/initialize()
at MethodInfo-1160()
at luckysoft.game::GameManager/run()
at Main/enterGame()
at Main/handleResourcesLoaded()
at flash.events::EventDispatcher/dispatchEventFunction()
at flash.events::EventDispatcher/dispatchEvent()
at luckysoft.utils.load::LoadSequence/callLoadQueued()
at flash.events::EventDispatcher/dispatchEventFunction()
at flash.events::EventDispatcher/dispatchEvent()
at luckysoft.utils.load::Load/handleLoadComplete()

и умерла.

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

[Котяра]

2Хомяк.

Идеологически правильно размещать логику приложения в модели (и, кстати, кто сказал, что модель должна быть монолитом и не слоится, как у вас контроллер?), если вы не согласны, то вообще говорить не о чем...

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

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

[JackFromChaos]

Мне, кстати, самому не нравится как написаны мои проекты в этом году... После двух летнего перерыва(меня за каким то хре#$м в game-design занесло, чур меня, чур), то что получалось не особо радует. Ну и учил as3 еще все таки... Вроде относительно освоился
Сейчас вот и вовсе ХО делаю... http://www.alawar.ru/game/mystery-of-mortlake-mansion/ Я еще когда game-design-ом занимался, эту игру возненавидел, а теперь делаю ее flash версию%)

Добавлено через 6 минут

Сообщение от Хомяк

и умерла.

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

Аха, чегой то она лежит, праздники блин

Сообщение от Котяра

2Хомяк.
Хотя тут конечно стоит вопрос, что понимать под бизнес логикой.
На самом деле скорее всего подразумевается логика изменения одних данных модели исходя из изменения других данных.

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

[Хомяк]

Сообщение от Котяра

Хотя тут конечно стоит вопрос, что понимать под бизнес логикой...

Ну вот, например, ПсихоТайгер демонстрировал реализацию MVC в своём блоге (часть 1) , там полученная инофрмация изменялась в контроллере, а потом сеттилась в модель... Вот. Мне кажется именно такой подход неправильным, чисто с идеологической точки зрения. Контроллер должен бы сообщать информацию, но не изменять параметры объектов приложения.
И, кстати говоря, если в модель не сеттить, то и "от дурака" защита не нужна, так как вьюха и не сможет изменять модель.

[Котяра]

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

[Хомяк]

Сообщение от Котяра

И всё же я предпочитаю этот слой выносить в отдельную сущность...

Он и должен выводиться в отдельную сущность, так и называется business logic layer, с этим я и не спорю.

Где то на Вики видел хорошую схемку, не смог найти.

Добавлено через 6 минут

Сообщение от Котяра

И не надо быть таким приверженцем идеологий. Это старпёрство) Надо брать то что подходит.

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

[JackFromChaos]

Сообщение от Хомяк

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

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

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

Кстати созрел вопрос. Допустим у нас есть активная модель, содержащие некоторые ноды с позициями. Скажем view эти ноды отображает как некоторые фигуры. У нас есть функционал drag&drop. Тут вроде как понятно. View обеспечивает некий полу-функционал drag&drop, отправляя новые позиции контролеру. Она меняет позиции в моделе, модель диспачит сообщение и view передвигает ноды.
Сообщение модель, вероятно, посылает в момент изменения свойства. Т.е. если контроллер делает нечто-вроде:

modelNode.x=x;
modelNode.y=y;

То во view за одну команду придет 2 сообщения. View 2 раза "перересуется", что, как бы не хорошо.

Пример немного искусственный, но гипотетически - вполне реальный. Понятно, что можно сделать функцию у modelNode - setPosition. И что 2 сообщения и 2 присвоения координат спрайту не такие уж большие затраты.
Но данные могли быть и более разнородными, а обновление более затратным.
Конечно, можно во view реализовать отложенный invalidate, который взводится по событию от модели.
Но, если мы его реализуем в общем view, то нам придется обновить каждую ноду. Ну а если внутри представления ноды, то вроде бы и все нормально... Хотя тогда представление ноды становится куда более тяжеловесным. Хотя может и нормально(чет пока задавал вопрос, сам ответ выдумал.. но может есть еще какие то варианты?)...

Да, кстати в процессе разработки примера столкнулся с тем, что родительский view во время ручного драга, не получает mouseMove, так как сцену перекрывает нода которую мы тащим. А подписываться на mouseMove в каждой ноде - как то не комильфо... Я конечно выкрутился, подписавшись на stage, но это тоже как то не особо красиво. Можно где нить забыть отключить обработчик, и получить нежданчик, вернувшись во вью с нодами из какого нибудь другого режима... Может есть какое то более элегантное решение?
Только следует помнить, что во время данного драга мы не должны двигать объект, а только сообщать об этом контроллеру.

[mikhailk]

То во view за одну команду придет 2 сообщения. View 2 раза "перересуется", что, как бы не хорошо.

По идее, вью перерисуется, когда модель сообщит ей, что она изменилась.
Что-то типа коммита для транзакции.
Ну или когда контроллер дернет вью, чтобы она обновилась.
Обновлять вью постоянно - будут слишком большие накладные расходы.