Хорошее MVC

[Dukobpa3]

вставь вложение

[in4core]

Как лучше протягивать баланс юзера в модельку shopItem?

Никак, в примере на скрине вариант лучший имхо только один :
Либо DB должна при запросе создания shop должна отсылать вам кеш , а создавать итем будете уже передавая в него кеш. Либо есть более изящный вариант :
В итеме подписываемся на событие добавления на сцену, из итема диспатчим событие шопу ( или чего у вас там вьюха) , ну а в шопе имеем баланс уже ( надеюсь ) , от него и рассылаем итемам задачу сменить цвет

[dimarik]

Как лучше протягивать баланс юзера в модельку shopItem?

Я сделал коллекции Condition и ComparisonObject. Первый по сути требования, условия. Второй -- то, что будем сравнивать с условиями. Сравнивать можно любые объекты, поддерживающие IComparator и IComparable.
ShopItem имплементит IComparator, с его методом compare. Метод принимает список ComparisonObject и возвращает Boolean (подошло/не подошло). У каждого магазина, его коллекции ShopItem'ов, самого ShopItem есть ссылка на User. User поддерживает интерфейс IComparable, метод которого getComparisonList(глагол):Vector.<ComparisonObject>, возвращает список доступных для сравнивания ComparisonObject;

getComparisonList извлекает предварительно подготовленные списки ComparisonObject. Их формированием и обновлением занимается сам IComparable, правила для этого находятся в нем.

Сама проверка можно ли купить предмет, с учетом скилов User и количества требуемой валюты сводится к одной строке

const canBuyItem:Boolean = shopItem.compare( shopItem.user.getComparisonList(покупать) );

Коллекция ShopItem -- ShopItemCollection тоже поддерживает интерфейс IComparator;
Достаточно накидать в нее некоторое количество shopItem, а затем и с ней провести сравнение.

const canBuyItems:Boolean = shopItemCollection.compare( shopItemCollection.user.getComparisonList(покупать) );

При этом будет учитываться количество, например денег, чтобы хватило на покупку всех айтемов. MoneyComprasionObject -> ChangeableComparisonObject -> ComparisonObject будет последовательно, с каждой проверкой уменьшать value. А вот, например, CharacteristicComparisonObject -> ComparisonObject и поэтому сравниваемая характеристика есть константа. Метода похожа на шаблон посетитель.

Итак, можно сравнивать все и вся, лишь бы была коллекция условий и то, с чем сравниваем. Можно померяться скилами UserData с коллекцией UserCollection.

userCollection.compare( userCollection.user.getComparisonList(меряться_скилами) );

Вот как-то так я это сделал.

[Sintesis]

А если приложение не связано с сетью и есть класс в который встроена вся графика и XML с некоторыми данными этот класс можно считать Model и по команде от Controller - View будет брать у него графику через геттер? Или вся графика сразу должна встраиваться во View?

[Dukobpa3]

хмл - модель.
графика - вью.

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

Или если графика заэмбежена - то бы сделал некий манагер, а в модели бы хранил ид-ы по которым вьюха сможет из манагера достать ассет.

Как-то так. А вообще по ситуации смотреть надо. В идеале должно быть так чтоб модель ничего не знала об ассетах. Чтобы можно было на одну модель повесить несколько вьюх, которые одни и те же данные по-разному отображают.

[Sintesis]

Наверное тогда класс в котором встроены все ресурсы будет каким-то хранилищем, а в модели будут храниться id. Условие такое, что скомпилиная флешка должна быть самодостаточной, то-есть в неё всё должно быть встроено и хочется, чтоб всё встроенное было в одном месте. В XML храняться данные о вершинах которые нужно парсить и больше ничего.

[Dukobpa3]

думаю норм будет.

[Sintesis]

И ещё вопросик, если есть кнопки, то они располагаются в View и диспетчат событие контроллеру или они публично открыты для контроллера и слушаются в нём?

[Dukobpa3]

Контроллер не знает про внутренности вьюхи, он слушает только ее.
А там уже вьюха шарит какое событие выпускать наружу при клике на кнопку.

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

[Sintesis]

Понятно, значит во вьюхе диспатчить буду.

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

Контроллер не знает про внутренности вьюхи

Но методы вьюхи контроллер может же вызывать? В примере ПсихоТайгера например: _view.updateSquares(); вызывается в контроллере. Или ты имеешь ввиду, что глубже заходить нельзя, например вот так
_view.updateSquares().someElse; ?