Интерфейс передачи данных: сервер -> флэш

[litebox]

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

Думаю, почти все скажут, что да, сервер важнее, поэтому приведу конкретный пример: сервер, написанный на си-шарпе, выбирает данные из базы данных, формирует свои классы и делает серриализацию в xml. На выходе получается что-то типа:

<object>
  <properties>
    <property name="posX" value="10"/>
    <property name="posY" value="20"/>
    <property name="name" value="vasya"/>
  </properties>
</object>

Так вот, парсить такое добро не очень удобно, так-как приходиться делать цикл for each, перебирающий все узлы properties, в котором реализован switch, определяющий, что если имя равно posX, то мы присваиваем координату объекта, если имя равно name, то присваиваем имя и т.д.
Я сколняюсь к варианту:

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

таким образом проще получить доступ к этим данным:

pos.x = String(data.@posX);
pos.y = String(data.@posY);
name = String(data.@name);

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

Какие есть соображения по этому поводу, и как можно облегчить флэшу доступ к свойствам объекта, если все же оставить первый вариант передачи данных?

[mooncar]

Вопрос небольшой - а зачем вам вообще нужен XML в данном случае? Получается, что сперва сервер у вас "выбирает данные из базы данных", формирует XML, а потом этот XML надо еще парсить, то есть теперь уже разбирать.
Может быть я что-то не понимаю? Разве нельзя данные сразу клиенту отдавать?

[Котяра]

а может компромисс?

<object>
  <properties>
    <posX value="10"/>
    <posY value="20"/>
    <name value="vasya"/>
  </properties>
</object>

или тогда:

<object posX="10" posY="20" name="vasya"/>

Кстати что-то ваш серверный программист темнит) вывести данные в виде атрибутов а не отдельных нодов никак нельзя назвать "ручным" выводом и на быстродействие никак не скажется.

[mikhailk]

+1 )))
темнит серверный программер
либо лень 20 строчек кода подправить, либо написано так, что он боится это трогать

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

но это не рассматриваемый случай

[litebox]

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

Вопрос небольшой - а зачем вам вообще нужен XML в данном случае? Получается, что сперва сервер у вас "выбирает данные из базы данных", формирует XML, а потом этот XML надо еще парсить, то есть теперь уже разбирать.
Может быть я что-то не понимаю? Разве нельзя данные сразу клиенту отдавать?

Ну, нам же нужно в каком-то виде передавать данные: простой GET-строкой, в виде xml или JSON, либо бинарные данные по сокету... В нашей реализации вся динамика передается по сокету, а статика - инициализация игровых объектов и собственно игрового уровня на их основе - одним POST-запросом, в виде xml-дерева.

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

а может компромисс?

<object>
  <properties>
    <posX value="10"/>
    <posY value="20"/>
    <name value="vasya"/>
  </properties>
</object>

или тогда:

<object posX="10" posY="20" name="vasya"/>

Кстати что-то ваш серверный программист темнит) вывести данные в виде атрибутов а не отдельных нодов никак нельзя назвать "ручным" выводом и на быстродействие никак не скажется.

Компромисс замечательный и вполне логичный, но в таком виде данные в си-шарпе серриализовать не получиться, а прийдется ручками писать модуль, который эти данные упаковывает в данной формат - и как итог, лишняя нагрузка на сервер, т.к. придется самостоятельно собирать xml-строку (я так это понял). Хотя что же это за серверная технология, который не умеет быстро производить конкатенацию строк... тут и PHP сгодился бы... (

[mikhailk]

Вас дурят. ))

Вот здесь на пальцах расписана сериализация на дот.нет'е
http://www.realcoding.net/articles/x...ps-tricks.html

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

[Котяра]

http://www.realcoding.net/articles/x...ps-tricks.html
2 вида сериализации:

<DataClass >
  <Name>Just Name</Name>
</DataClass>

и

<Data Name="Just Name"/>

UPD: блин.. опередили)
одним гуглом пользовались)

[mikhailk]

)))))))
я пользовался "негуглом", но сути это не меняет ))

[litebox]

За ссылку по серриализации спасибо - врага нужно знать в лицо ))))
Я, пожалуй, не совсем верно выразился:
дело в том, что элемент

  <properties>
    <property name="posX" value="10"/>
    <property name="posY" value="20"/>
    <property name="name" value="vasya"/>
  </properties>

получается в следствии того, что это серриализованный массив, т.е. на стороне сервера политика такая: база данных должна масштабироваться "вдоль и поперек", все свойства объектов - могут быть в любой момент добавлены или, наоборот, удалены, поэтому серверный класс-обертка, который получает данные из базы, без разбору набивает ими массив properties, и отдает их серриализованный вариант флэш-клиенту. С моей же стороны, конкретный объект обладает вполне конкретными свойствами, которые я ожидаю получить, т.е. если это "ОсновнойОбъектМира" - я должен получить его ширину, высоту и т.д., если это "Персонаж" - в добавок к ширине и высоте мне нужен список его анимаций и т.д.

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

[mikhailk]

это ничего не меняет (почти ничего)
серверному программисту надо правильным образом указать [XmlAttribute] в этом "одном-на-все-случаи-жизни" классе и все.

Получите все пропертис не в виде нодов, а в виде атрибутов. Одним из атрибутов, очевидно, будет тип объекта, чтобы было понятно, что с этим всем делать.

Там в примере все написано:

public class DataClass
{
    public DataClass(){}
    public string ID = Guid.NewGuid().ToString();
    public string Name = "Just Name";
    public Decimal Count = 10;
    public DateTime Date = DateTime.Now;
}

дает

<?xml version="1.0" encoding="utf-8"?>
<DataClass xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
  <ID>34332413-e70f-44f7-b35c-b34c47812dbc</ID>
  <Name>Just Name</Name>
  <Count>10</Count>
  <Date>2006-10-30T12:35:20.3110319+03:00</Date>
</DataClass>

а всего навсего указание [XmlAttribute]:

[XmlRoot("Data")] // изменим имя корневого элемента
    public class DataClass
    {
           public DataClass(){}

           [XmlAttribute] // сериализуем в xml атрибут 
           public string ID = Guid.NewGuid().ToString();

           [XmlAttribute] // сериализуем в xml атрибут 
           public string Name = "Just Name";

           [XmlElement("Reserved")] // изменим имя xml элемента
           public Decimal Count = 10;

           [XmlIgnore] // не будет сериализоваться
           public DateTime Date = DateTime.Now;
    }

кардинально меняет картину:

<?xml version="1.0" encoding="utf-8"?>
<Data xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" ID="cc340d5e-4c80-4fe5-9c3d-e49f64e26b22" Name="Just Name">
  <Reserved>10</Reserved>
</Data>