Кто и как хранит данные в конфигах?
 

Интересно ваше мнение. Здесь много сторонников MVC подхода. Если рассматривать Model, как Data контейнер, то в каком формате вы храните там данные: xml, object, json или же под каждое поле создаете переменные (ветвите модели). Ну вопрос, конечно, актуален и не для MVC.

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

Ну сразу оговорюсь про себя. С сервером мы общаемся посредством xml, потому сложные структуры так и хранятся, ну а простые, как обычные свойства классов.

В общем, поделитесь своим опытом.

P.S. Тему немного странно назвал, ну я еще сплю :)

Лично я использую VO под это дело, если брать именно информационные классы, такие как : Version или ApplicationInfo : [version, creator, date]... , то можно хардкодить константы и делать их статическими.

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

xml и json - для сохранения данных в текстовом формате. Object - для хранения пар строка-переменная (где какая именно строка - сложно предугадать). Если известна структура, то лепить структуру (POD классы).
Ну вот как-то так, по капитански)

Если нужны выборки с условиями, то тут встает вопрос - какие выборки

Ну продолжении темы товаров магазина: имеем загруженный xml с сервера со списком всех товаров. А показывать в клиенте их нужно по рубрикам.

Ну как-то так. Допустим, нужно отобразить товары с rubric_id = 1, Вот такие структуры у меня хранятся, как и пришли с сервера, в xml, ибо удобно. Но интересно - может существует более тру подход.

У нас тяжелый клиент. Все храним в БД в "нормальном" виде, разбитые по полям. Есть поля, которые нужны серверу / серверу и мне / только мне. То что нужно только клиенту - хранится как JSON. Практически у каждой сущности есть поле settings. А кидаемся хмльками. Списочные данные выкачиваются при старте флэшки. Прилетает несолько хмл-простыней, парсятся в массивы/хеши с нормальными объектами.

Локали и конфиг флэшки просто хмльки рядом с флэшкой лежат.

Добавлено через 3 минуты
Не знаю насколько тру, но терпеть не могу динамические объекты. Распарсил бы в объекты пихнул в массив и фильтровал по rubricId.

А в чем фишка парсить xml в массив объектов? Если xml фактически есть объект с удобным поиском

я храню в xml а парсю в статически типизированные объекты, т.е. у меня есть классы и штука которая по xml создаёт объекты соответствующих и заполняет, а также выполняет верификацию. Плюс в статической типизации и проверке на этапе компиляции.

У меня у объектов от 5 до 40 параметров, вспоминать как их назвал серверный прогер меня не радует. Кроме того, там есть временные параметры для ускорения работы, генерящиеся из других параметров. Для простых приложений я тоже скорее всего буду использовать, а может не буду - не люблю.

Завтра на сервере скажут, что магазин увеличил кол-во товара, и теперь рубрики станут подрубриками, а рубриками будет что-то другое, и теперь проперть будет называться sub_rubric_id. Сколько классов вам надо бдет изменить? Мне один.

На прошлой работе пробовал написать генератор из XML в AS. Но его очень трудно было бы сделать универсальным, да и XML - совсем не лучшее место для хранения настроек. Еще делал генератор из SQL в AS - не особо удобно пользоваться, особенно, если SQL плохо знаешь :) Была мысль написать генератор AMF данных, но возникла неопределенность с форматом ввода :) Но если когда-нибудь руки дойдут и придумаю как именно сделать ввод удобным - последнее, наверное, было бы самым хорошим вариантом.