![]() |
Кто и как хранит данные в конфигах?
Интересно ваше мнение. Здесь много сторонников MVC подхода. Если рассматривать Model, как Data контейнер, то в каком формате вы храните там данные: xml, object, json или же под каждое поле создаете переменные (ветвите модели). Ну вопрос, конечно, актуален и не для MVC.
Как хранятся у вас сложные структуры данных? Ну первый пример, приходящий на ум, - это товары в магазине, которые могут фильтроваться по рубрикам, сортироваться по цене, ну и другие критерии. Как обновляете (удаляете/добавляете) такие структуры? Ну сразу оговорюсь про себя. С сервером мы общаемся посредством xml, потому сложные структуры так и хранятся, ну а простые, как обычные свойства классов. В общем, поделитесь своим опытом. P.S. Тему немного странно назвал, ну я еще сплю :) |
Лично я использую VO под это дело, если брать именно информационные классы, такие как : Version или ApplicationInfo : [version, creator, date]... , то можно хардкодить константы и делать их статическими.
|
Ну на самом деле больше интересуют ситуации, когда требуется делать выборки данных с условиями. На сервер же не будешь по каждому чиху отправлять запрос, ибо хайлоад. Вот для таких целей, мне кажется вполне подходит XML
|
xml и json - для сохранения данных в текстовом формате. Object - для хранения пар строка-переменная (где какая именно строка - сложно предугадать). Если известна структура, то лепить структуру (POD классы).
Ну вот как-то так, по капитански) Если нужны выборки с условиями, то тут встает вопрос - какие выборки |
Цитата:
Код:
<items> |
У нас тяжелый клиент. Все храним в БД в "нормальном" виде, разбитые по полям. Есть поля, которые нужны серверу / серверу и мне / только мне. То что нужно только клиенту - хранится как JSON. Практически у каждой сущности есть поле settings. А кидаемся хмльками. Списочные данные выкачиваются при старте флэшки. Прилетает несолько хмл-простыней, парсятся в массивы/хеши с нормальными объектами.
Локали и конфиг флэшки просто хмльки рядом с флэшкой лежат. Добавлено через 3 минуты Цитата:
|
А в чем фишка парсить xml в массив объектов? Если xml фактически есть объект с удобным поиском
|
я храню в xml а парсю в статически типизированные объекты, т.е. у меня есть классы и штука которая по xml создаёт объекты соответствующих и заполняет, а также выполняет верификацию. Плюс в статической типизации и проверке на этапе компиляции.
|
У меня у объектов от 5 до 40 параметров, вспоминать как их назвал серверный прогер меня не радует. Кроме того, там есть временные параметры для ускорения работы, генерящиеся из других параметров. Для простых приложений я тоже скорее всего буду использовать, а может не буду - не люблю.
Завтра на сервере скажут, что магазин увеличил кол-во товара, и теперь рубрики станут подрубриками, а рубриками будет что-то другое, и теперь проперть будет называться sub_rubric_id. Сколько классов вам надо бдет изменить? Мне один. |
На прошлой работе пробовал написать генератор из XML в AS. Но его очень трудно было бы сделать универсальным, да и XML - совсем не лучшее место для хранения настроек. Еще делал генератор из SQL в AS - не особо удобно пользоваться, особенно, если SQL плохо знаешь :) Была мысль написать генератор AMF данных, но возникла неопределенность с форматом ввода :) Но если когда-нибудь руки дойдут и придумаю как именно сделать ввод удобным - последнее, наверное, было бы самым хорошим вариантом.
|
Цитата:
Вань, это вопрос преобразования данных. Я их также могу пропускать через некоторый посредник, преобразовывая в удобоваримый тип. И этот удобоваримый тип также может быть XML, а не массив объектов. Вот. |
хмл в хмл, мсье знает толк в извращениях. :о))
|
Ну я такой подход не применяю, ибо это не есть хорошо:) Это скорее некое абстрактное суждение) Я написал это применительно к вопросу, в чем преимущество массива объектов перед xml.
Ну даже не так. Мне не нужно применять поход с посредником в принципе, ибо данные с сервера приходят в нормальном виде. И я спрашиваю, какой смысл мне перегонять данные из xml в массив объектов, ежели я получу ровно ту же самую структуру. Вот. |
Вот пример как из xml делать VO, ну просто так для галочки сюда выложу :
Код AS3:
Код AS3:
|
wvxvw, Genzo
Я использую простую систему. Все объекты, которые заполняются из хмл, имеют конструктор вида function FromXMLObject(xml:XML=null) и там параметры раскидываются куда надо. когда прилетает хмл есть утилитная функция Код AS3:
|
Код AS3:
|
От варианта Genzo отказался пару лет назад, почему не помню, но сейчас он мне кажется более адекватным, чем мой. Хм.
|
Цитата:
|
решил открыть свой велосипед
https://bitbucket.org/Aquahawk/configmanager/ Тесты там ни к чёрту, доки нет, часть туду в коде, но я этим пользуюсь. Можно считать что это pre alpha Добавлено через 38 секунд гитигнор не настроен, билд скрипты не вынесены отдельно |
Цитата:
|
лучше так
Код AS3:
Код AS3:
|
У XML есть несколько существенных недостатков:
<foo bar="100"/> - bar число или строка, если число, то какой разрядности? SQL таким не страдает. <foo><bar/></foo><foo><bar/></foo> - первый bar и второй - это один и тот же объект, или нет? AMF этим не страдает. В SQL можно договориться, что ключи - это ссылки, а остальные значения - всегда не-ссылки. Для AIR, наверное, самым правельным было бы использовать встроенный SQL, для веб - я бы наверное все-таки написал какой-нибудь конвертор на том же AIR, который бы нужные данные экспортировал в AMF и потом бы я их просто встраивал / загружал - что по ситуации подходит. |
Если использовать выше указанные классы, то первый недостаток - таковым не является.
Если писать нечто универсальное, то да. Вот второй недостаток уничтожается при "десериализации" в нормальные объекты, при использовании вышеуказанных методов. |
Цитата:
Цитата:
Добавлено через 9 минут Цитата:
Добавлено через 12 минут Цитата:
Добавлено через 21 минуту Цитата:
null зачем? Вероятно, лоадер будет использоваться еще не один раз. Каждый раз создавать заново лоадер? Это антиоптимизация. |
Обычно поступаем так:
Есть конфиг клиента - это просто список поле-значение в xml, причем если через флеш-варс передали такое же поле как в конфиге - оно перетирается (это позволяет использовать конфиг лежащий на сервере, поправляя данные в HTML-ке чтобы грузиться локально - ну это если лень локальный конфиг создавать полностью). В конфиге обычно храниться информация что откуда брать - то, что зависит от места запуска флешки, не более. Остальные данные от сервера делятся на статические и динамические. Динамические - это то, что клиент получает, отправляя запросы Статические - это так называемые "справочники" - там начиная от списка товаров с параметрами, заканчивая геометрией "фермы" и общими с сервером константами На клиенте представлены набором классов, которые парсят их в типизированные объекты, типа Код AS3:
Цитата:
- фильтры могут зависеть от динамических параметров - фильтры всетки больше логик отображения чем данных Поэтому фильтрация идет обычно прямо в классе диалогового окна, или в классе-контроллере диалогового окна (если окно повторно используется в нескольких местах) |
Цитата:
Добавлено через 4 минуты Цитата:
А чуть подразгонятся, то и динамика туда же. |
Код AS3:
Еще есть проблема: "как эту swf серверу парсить - он же те же данные использует?" Но было бы интересно узнать подробности про способ и преимущества загона в swf |
Совершенно не одобряю этой суеты, вы правильно подметили. Мне на работе это обрыдло.
Разговор зашел о якобы "парсинге". Преобразование одного и того же по сути, но запечатленного в разных конструкциях. Давайте просто говорить на одном языке. Клиент умеет много гитек, в т.ч. заниматься ненужными конвертациями, высокопарно названными "парсингом". |
Все-таки хотелось бы узнать:
- что идет на входе в swf - как с этой swf работает сервер (или она генерится сервером? тогда по каким данным?) - что получает клиент из этой swf и как с ней работает |
- Простите, не понял;
- Генерирует сервер по протоколу; - Клиент получает объект (character, item, что-то еще, что я упустил). Альтернативе (3Д, которая) не откажешь в гибкости. |
с одной стороны получается
- xml - парсинг на сервере - парсинг на клиенте с другой - протокол (в каком формате, кстати?) - парсинг на сервере - генерация на сервере По трудозатратам примерно тоже самое (однако со вторым случаем придется повозиться с генератором swc/swf/as3). Но, как я понимаю есть один большой плюс: работа с протоколом сосредоточена в одном месте - на сервере, т.е. осутствуют проблемы синхроницации протоколе, сложнее ошибиться на клиенте. А если вспомнить про динамику - то сложнее ошибиться и при отправке/обработке запроса Но, ИМХО для проектов средней сложности дешевле работать с парсингом, меньше граблей, на которые можно напороться, нет? Цитата:
|
Цитата:
Для небольших проектов, вероятно, велосипед может оказаться пятиколесным. |
Более-менее понятно.
Т.е. протокол - это просто доки получается. А объекты то сами откуда берутся, из базы? Или "Я клиент, ничего не хочу знать, кроме того, что здесь лежить swf со статикой, а вот на эти запросы мне вернут динамику, которую я просто дисериализую в типизированные объекты?" А, ну у нас, кстати, были проекты, в которых хранилищем статики была не xml, а база и специальный серверный скрипт генерил xml исключительно для клиента. Можно, наверное, было и в amf и в сериализованные типизированные объекты генерить, но как-то серверист не горел желанием трахаться с генератором, а клиентщиков вообще не напрягал парсинг. Просто точка "!№;;!! Опять изменился протокол, где это долбаное поле?!! Что здесь должен присылать сервер!!?" была очень-очень далеко и так и не наступила по сравнению с другими проблемами. |
Цитата:
Второй недостаток никак этим не "лечится" - как вы из XML поймете, что объект создается по ссылке (т.е. не создается вообще)? |
XML нужен для людей, а не ЭВМ. Передача информации в этом формате сопряжена, как сказал бы мой коллега, с большим оверхедом. Сравните русский и английский языки. Первый для передачи эмоций.
Но если вы читаете байткод как Кира Булычева, то можете игнорировать мои заявления. |
Да нет такой связи... XML - только один из возможных форматов, со своими недостатками. Вообще изначально даже не задумывался для хранения информации, только для презентации. Тот же Protobuf при том, что в исходнике не менее читаемый, не страдает такими недостатками.
Кстати, раз уж мы заговорили о презентации информации, то, например, предствить табличные данные так, как это делает SQL - это гораздо более читаемо, чем XML. Там сaрзу же и на колонки разбито, и выравнено + заголовки над колонками говорят о типе и назначении поля - гораздо удобнее что-то искать / сравнивать значения и т.п. |
Да есть такая связь, есть. Но я уважаю чужое мнение и не могу с ним не согласиться.
Зачем для передачи информации (все помнят, что такое бит?) кодировать бит с оверхедом over 9000? |
Цитата:
Значит dimarik за честную (де)сериализацию? Где вы таких покладистых серверных прогеров находите? :о)) |
Цитата:
|
Под статикой для "фермы", вероятно, подразумевались прототипы объектов в рамках предметной области приложения. Имеем один раз сформированный файл (я предложил, в формате swf) со списком таких предметов (синонимы: артикул, шаблон). Например, есть предмет на грядке protoId=1, id=1, count=2. По protoId узнаем остальные характеристики (цвет, название, стоимость, что-то еще, что общее для такого типа объекта) предмета из статического списка. Собрали с грядки один предмет (count-1), получили второй предмет protoId=1, id=2, count=1. Первый предмет изменил свой count на count=1. Так вот динамика передается сервером и определяет что остается на грядке и что собрано.
Вернемся к вашему вопросу. Динамические структуры я не храню. Я меняю модель. Если модель динамическая структура, а она динамическая, то я храню ее... в памяти ) В общем, я не понял вопроса. |
| Часовой пояс GMT +4, время: 17:39. |
Copyright © 1999-2008 Flasher.ru. All rights reserved.
Работает на vBulletin®. Copyright ©2000 - 2026, Jelsoft Enterprises Ltd. Перевод: zCarot
Администрация сайта не несёт ответственности за любую предоставленную посетителями информацию. Подробнее см. Правила.