[php][передача объектов] Как правильно?

http://www.php.net/manual/en/language.oop5.serialization.php

Это то я все знаю. А если кол-во переменных в объекте уползет за ограничение сессии? И тут вопрос все таки что разумнее - использовать serialize, использовать хранение в файлах или есть еще варианты?

Если объекты однотипные напиши свой serialize или что-то вроде function __toString() для того, чтобы исключить лишние данные и метод, который из твоей строки будет создавать объект.

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

у меня в Java EE он таскается через память, с использованием передачи ссылки в POST.

>А если кол-во переменных в объекте уползет за ограничение сессии?

А такие объекты точно не требуют рефакторинга? :)

И тут вопрос все таки что разумнее - использовать serialize, использовать хранение в файлах или есть еще варианты?

Я у себя использую serialize для сохранения в кеше БД или memcached. Точно также можно и в файлы класть.

ну тащемта есть Serializable (или как), неужели нельзя типо прозрачно это сделать ?

>неужели нельзя типо прозрачно это сделать ?

Давай чётче задачу формировать. Что за объекты такие, что в сессию не лезут? Там что, огромные блобы? Тогда их - в файл.

Что за нагрузка, что в БД совать нельзя? Если менее 1000 запросов в секунду, то можно и забить, не занимаясь преждевременной оптимизацией...

ну я вообще не вопрошатель, но вот ты считаешь что в сессию писать сериализованные объекты это кошерно?

А почему просто в сесию не положить объект? Зачем его сериализировать?

>но вот ты считаешь что в сессию писать сериализованные объекты это кошерно?

Сам так не делаю, надобности не было, но почему бы и нет, если понадобится? :) Не вижу ничего некошерного.

>А почему просто в сесию не положить объект? Зачем его сериализировать?

Чтобы объект оторвать от рантайма PHP, его нужно сериализовать. Явно или неявно.

Постоянно клал юзера без проблем.

php научился сериализации ?

наверное у него был реализован serialize ?

ну вот есть мазагин, в магазине корзина, корзина в сессии, добавил ты в корзину товар, товар удалили из магазина, что дальше?

Да нет же.
Я точно не помню, там только один момент был с инклудом файла с классом. Там он должен до стартсешн идти, вроде.

>Постоянно клал юзера без проблем.

Я же сказал - явная или _неявная_ сериализация :) Когда ты сохраняешь объект в сессию (или тот же memcached), то сериализация происходит неявно. Пропиши трейс вызовов __sleep() - увидишь.

>php научился сериализации ?

Более 10 лет назад. В 4-й версии.

>ну вот есть мазагин, в магазине корзина, корзина в сессии, добавил ты в корзину товар, товар удалили из магазина, что дальше?

Вот поэтому я храню в сессии обычно не объект, а связку class_name + object_id. Но часто объекты можно хранить в сессии и целиком.

В общем, как и всюду, требуется использование мозга :)

> php научился сериализации ?

толсто, ты даже не представляешь сколько всего умеет php

>Более 10 лет назад. В 4-й версии.

Ого. Не знал.

А дефолтный серилизатор как в Java появится через следующие 10 лет ? В смысле маркерного интерфейса Serializable, transient-полей, ObjectStream-ов и т.д.

>толсто, ты даже не представляешь сколько всего умеет php

Ну нифига себе, и unicode тоже умеет ? И давно ?

> Ну нифига себе, и unicode тоже умеет ? И давно ?

Всегда умел)

Всегда умел)

Неужели ?

Разве что через mb_костыли

> Разве что через mb_костыли

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

Толсто, толсто...

Зачем из PHP делать Java, если уже есть Java?

>Зачем из PHP делать Java, если уже есть Java?

Встречный вопрос: зачем нужен php, если есть Java ? С тем же unicode, сериализацией ... и пр.

>Встречный вопрос: зачем нужен php, если есть Java ?

- Другая идеология построения сервера (запуск изолированного рантайма при каждом обращении)
- Более простой процесс написания и отладки
- Большая распространённость на хостингах
- Более простая виртуализация и разделение прав доступа на массовых хостингах
- Динамика против статики.
- И т.д. и т.п.

С тем же unicode, сериализацией ... и пр.

Так и в PHP с этим никаких проблем :) Также, как нет и, скажем, проблем с утечками памяти ;)

...

Я, как бы, сам не один год программировал и на Java, и на PHP. Так что знаю массу достоинств и недостатков Java. И вполне уважаю этот язык, где-то даже люблю :D Но сайты пишу сегодня на PHP. В разных нишах эффективны разные языки.

>Я, как бы, сам не один год программировал и на Java, и на PHP. Так что знаю массу достоинств и недостатков Java. И вполне уважаю этот язык, где-то даже люблю :D Но сайты пишу сегодня на PHP. В разных нишах эффективны разные языки.

Я дальше PHP4 в свое время не ушел :-) И ведь есть Perl, чем он хуже ?

> Я дальше PHP4 в свое время не ушел :-) И ведь есть Perl, чем он хуже ?

Perl нечитаем вообще

>И ведь есть Perl, чем он хуже ?

Ну, я 8 лет назад с Perl'а на PHP перелез по прозаической причине. mysql_* функции в PHP работали в 9(!) раз быстрее, чем через DBI в Perl :) Так что, не смотря на то, что числодробильно PHP сливал тогда Perl'у вдвое, пришлось переходить на PHP.

...

Ну а потом накопилось много кода и оказалось, что на PHP его [годы спустя] поддерживать много проще, чем на Perl'е :)

Дурную славу PHP делают вот так http://www.linux.org.ru/forum/talks/4965660

«Мне нечего сказать на это» (c) :)