Форум Flasher.ru - Интерфейс передачи данных: сервер -> флэш

Форум Flasher.ru (http://www.flasher.ru/forum/index.php)

- Серверные технологии и Flash (http://www.flasher.ru/forum/forumdisplay.php?f=62)

- - Интерфейс передачи данных: сервер -> флэш (http://www.flasher.ru/forum/showthread.php?t=140336)

другое дело, что атрибутами можно задать только простые типы ( числа/строки)
а если это составной объект или массив?
тогда только нодами, но лучше сделать так:

Код AS3:

<player type="object">

    <posX type="integer">10</posX>

    <name type="string"> vasya </name>

    <pet type="object"> 

           <posX type="integer">10</posX>

           <name type="string">Шарик </name>

   </pet>

</player>

Все это так, но класс нашего программиста выглядит примерно так:

Код:

public class ObjectClass

    {

        public List<PropertyClass> Properties { get; set; }

    }

И все свойства объекта (поля, полученные из базы) просто добавляются в массив Properties, поэтому и после серриализации получается узел <properties>, где каждый дочерний элемент - элемент массива Properties, который является экземпляром PropertyClass, который, в свою очередь, серриализуется в виде, например, таком:

Код:

<property name="posX" value="10"/>

Поэтому серриализовать это в виде

Код:

<properties posX="10" posY="20" name="vasya">

или

Код:

<properties>

    <posX value="10"/>

    <posY value="20"/>

    <name value="vasya"/>

  </properties>

никак не получится, это нужно делать руками

мне вообще эта пара name->value здорово напоминает таблицу параметров настроек сайта... Но там их немного и требований по быстродействию нет...

Интересно, а такая технология, когда вообще все свойства всех игровых объектов лежат в текстовых полях одной таблицы, она вообще насколько широко применяется?

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

При этом, кстати, switch не нужен.
Просто проходите по списку пропертис и для каждого айтема берете name/value и делаете из них атрибут/значение в новом xml, который и используете далее.

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

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

Цитата:

Сообщение от mikhailk (Сообщение 911376)

Да, именно по этому пути я и пошел, а читать поля, действительно, лучше без switch, где-то так:

Код AS3:

for each(var n:XML in xl)

{

        var varNameStr:String = n.@name;

        var varTypeStr:String = n.@type;

        var varValueStr:String = n.toString();

 

        if(hasOwnProperty(varNameStr))

        {

                try

                {

                        this[varNameStr] = varValueStr;

                }

        }

}

Просто проектированием и разработкой баз данных я никогда не занимался, и не могу судить о правильности или неправильности действий нашего человека, поэтому было интересно Ваше мнение по этому вопросу. И вообще, самый главный вопрос: даже если ты проектируешь базу данных очень грамотно и масштабируемо, не должен ли ты делать "обертку" (которая занимается выборкой этих данных и передачей их на сторону клиента) четко заточенную под конкретную реализацию клиента игры? Я сколняюсь к мнению, что должен.

У серьезного приложения должен быть архитектор. Даже если этого человека нет, функции архитектора все равно кто-то выполняет. То, о чем Вы говорите - протокол взаимодействия клиент-сервер - как раз уровень компетенции архитектора.

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

Кстати, по поводу кода - а зачем try, да еще и в обрезанном виде?

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

Что-то мне интуитивно кажется, эксепшна там быть не может по определению.