сериализация - десериализация

[Akopalipsis]

Dukobpa3 последовал Вашему совету и половина вопросов отпала, но появилось ровно столько же. я решил подумать, что я хочу. Получилось, что мне нужно
1) Хранить данные на сервере.
2) Мне нужно заполнить данными значения свойств классы для которых эти данные предназначались.
Казалось бы не так много я и хочу, но эти два пункта как фраза - купить фрукты, без уточнения какие.
Чтобы обьяснить ещё более честнее - я не знаю. У меня в голове вообще тупик, который пока я не преодолею не сдвинусь дальше. Расскажите мне что нибудь)

Добавлено через 24 минуты
я сейчас ещё раз перечитал всё по ссылке которую привел в пример Babylon, но там говорится о готовом решении, да и то с указанием строгой типизации и ещё чего то. я нашел тоже готовое, но там даже не чего указывать не надо и как то все тоже самое делается. Вопрос не в велосипеде, а в усвоении процесса. Если не учить самому, а только пользоваться готовом, то для меня это выглядит, как кадры и компоненты.

Добавлено через 2 минуты
я мало понимаю, но мне без разницы формат хранения. Пусть хоть какой будет. я не понимаю, как потом этот формат присвоить в качестве значения классу для которого он предназначен.

[Dukobpa3]

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

[Akopalipsis]

Пока у меня вот какие рассуждения - про xml я не первый раз слышу не лестные отзывы и понимаю почему, слишком он тяжелый. Если делать выбор сейчас, то предпочтения будут перевешивать в сторону json, потому что я много слышал про него и уже сейчас знаю, что использование.. точнее сказать - учиться на нём сейчас, значит использовать актуальную технологию. Про сам json знаю очень мало, но понимаю что его полезно использовать. И тогда я чтобы не упускать момент спрошу - какая самая быстрая библиотека для работы с ним?
И ещё не понятно про Protobuf. Он аналог xml? Можно его использовать так же как и json? Быстрее он?

[mikhailk]

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

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

С транспортом тоже не все так очевидно. Мне кажется, для многих задач такой сериализации, как json - за глаза и за уши.

Что касается сравнения xml и json по компактности, то разница по объему "сильно преувеличена" (см. пример ниже), но читаемость у json-а практически нулевая, если только не приводить его к читабельному виду специально, а у xml - более-менее. Кроме того, для флеша - xml нативный, что тоже немаловажно.

// xml
<service timePointStart="12456789"  timePointFinish="12459789" cost="2000" />

// json
{"service":{"timePointStart":"12456789","timePointFinish":"12459789","cost":"2000"}}

[KumoKairo]

mikhailk, а как же примеры побольше? Например

<car>
//XML
   <company>Volkswagen</company>
   <name>Vento</name>
   <price>800000</price>
</car>

//JSON
{
   "company": Volkswagen,
   "name": "Vento",
   "price": 800000
}

//XML
    <employees>
      <employee>
        <name>John Crichton</name>
        <gender>male</gender>
      </employee>
      <employee>
        <name>Aeryn Sun</name>
        <gender>female</gender>
      </employee>
    </employees>

//JSON
    {
      "employees": [
        {
          "name": "John Crichton",
          "gender": "male"
        },
        {
          "name": "Aeryn Sun",
          "gender": "female"
        }
      ]
    }

JSON не зря называют "Обезжиренной" версией XML, да и потом, c недавних пор (с фп 11) JSON тоже является нативным форматом для флеш (до этого времени была отдельная библиотека, если не ошибаюсь).
У нас в универе преподаватели помню тоже очень скептически относились к этому формату, сколько ни обсуждали с ними различия/плюсы/минусы, всех таки заставляли использовать XML, не шли ни на какие уступки )

Akopalipsis, Protobuf тоже в голове держите, это наиболее компактный из всех (из трех - XML, JSON, Protobuf) способов (отлично для передачи критичных ко времени данных) и его, в отличие от XML и JSON нельзя сходу прочитать и понять что там и как. При этом сам формат передаваемого сообщения (поля и их возможные значения) задаются целиком на этапе проектирования

[Akopalipsis]

хранить в ней в сериализованном виде профиль пользователя - это весьма спорное решение

mikhailk Спасибо Вам, для меня это очень полезная информация, о которой я обязательно буду помнить.

JSON не зря называют "Обезжиренной" версией XML, да и потом, c недавних пор (с фп 11) JSON тоже является нативным форматом для флеш (до этого времени была отдельная библиотека, если не ошибаюсь).

я пока остановлюсь на нёт, так как все равно рано или поздно пришлось бы его использовать и попрактиковаться сейчас, это даже к лучшему. Но вот я вчера наткнулся на тему на этом форуме, где автор приводил время хода сериализации адобовских классов и его собственных. Разница была умопомрачительная, от 2000 тысяч адоб, 70 его. я не гений и претендовать на него даже в голове нет, а использовать сериализацию хочется уже сейчас. И от сюда вопрос - какая лучшая библиотека для сериализации json? Спасибо.

Добавлено через 48 минут
Может кто нибудь подкинуть правильное направление в вопросе - как наполнить модель данными?
Потому что для меня только один путь известен - строку, распарсить regexp на ключ-значение, набить ими массив и потом ключи подставлять как свойство класса class['key'] = val;
Но мне кажется это не правильное направление. Или я ошибаюсь?

Добавлено через 46 минут
Что бы не сидеть и не смотреть в экран, решил сделать парсер класса, что бы не писать руками все свойства и методы. Использую для этого describeType() так как лучше не чего не знаю. Информацию этот метод хорошую предоставляет, но нет значений, а вместо этого есть не понятная мне строчка

<arg key="pos" value="58"/>

<arg key="pos" value="90"/>

Может знает кто нибудь, что это? и если это значения то в каком формате?

[Dukobpa3]

а как же примеры побольше?

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

Добавлено через 1 минуту

<car 
    company="Volkswagen" 
    name="Vento" 
    price=800000 />

//JSON
"car":{
   "company": Volkswagen,
   "name": "Vento",
   "price": 800000
}

Добавлено через 4 минуты

//XML
    <employees>
      <employee
        name="John Crichton"
        gender="male"
      />
      <employee
        name="Aeryn Sun"
        gender="female"
      />
    </employees>

//JSON
    {
      "employees": [
        {
          "name": "John Crichton",
          "gender": "male"
        },
        {
          "name": "Aeryn Sun",
          "gender": "female"
        }
      ]
    }

Добавлено через 5 минут

так как лучше не чего не знаю.

describeType() - описывает структуру, а не данные которые в ней содержатся. Это совсем в другую степь.

[Котейка]

Для того у нас и есть JSON и XML чтобы строку не парсить на ключ/значение
На самом простом примере MySQL, PHP и Flash:

Mysql:

//Имеем таблицу users
user_id, user_name, user_age

PHP:

PHP код:

//Берем данные из базы и отдаем клиенту
if(isset($_POST['uid']))
{
   $id = (int)$_POST['uid'];
   $result = $db->query("SELECT * FROM users WHERE user_id = " . $id);
   $array = $result->fetch();
   echo json_encode($array);
} 


AS:

...
 
var variables:URLVariables = new URLVariables();
variables['uid'] = 1;
 
var request:URLRequest = new URLRequest("http://mysite.ru/index.php");
request.method = URLRequestMethod.POST;
request.data = variables;
 
var loader:URLLoader = new URLLoader();
loader.addEventListener(Event.COMPLETE, onLoad);
loader.load(request)
 
...
 
private function onLoad(e:Event):void 
{
	e.currentTarget.removeEventListener(Event.COMPLETE, onLoad);
	var data:Object = JSON.parse(e.currentTarget.data);
	var user:User = new User(data);
}
 
//И класс User
package 
{
	public class User 
	{
		private var _id:int;
		private var _name:String;
		private var _age:int;
		public function User(data:Object)
		{
			_id = int(data.user_id);
			_name = data.user_name;
			_age = int(data.user_age);
		}
	}
}

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

Но вот я вчера наткнулся на тему на этом форуме, где автор приводил время хода сериализации адобовских классов и его собственных. Разница была умопомрачительная, от 2000 тысяч адоб, 70 его. я не гений и претендовать на него даже в голове нет, а использовать сериализацию хочется уже сейчас. И от сюда вопрос - какая лучшая библиотека для сериализации json? Спасибо.

Не забивайте себе этим голову. Вы же не андроинный коллайдер изобретаете. JSON не то место, где надо всерьез думать о производительности в 90% проектов. Лучше сконцентрируйтесь на производительности своего кода и отрисовке графики, именно там куда больше потенциальных тормозов, нежели в производительности адобовских либ.
-----

но читаемость у json-а практически нулевая, если только не приводить его к читабельному виду специально, а у xml - более-менее.

Это довольно спорный вопрос. JSON кажется не читабельным для тех кто привык работать с HTML и XML. А для тех кто привык оперировать объектами наоборот.

[mikhailk]

да и потом, c недавних пор (с фп 11) JSON тоже является нативным форматом для флеш (до этого времени была отдельная библиотека, если не ошибаюсь).

Дудки. Просто парсер переехал.

[Babylon]

считать закрывающие скобки удобнее чем теги