Php сериализация объектов

[Apostol]

У меня есть свойство класса, которое хранит параметры пользователя (имя, ид, данные профиля и т.п.).
Подскажите, как сохранять состояния объекта при переходе между страницами.
Что бы авторизация не падала и не надо было каждый раз базу дергать.
Поместить объект в $_SESSION мне только приходит в голову пока.

 

[С.]

Не надо сохранять объекты при переходе между страницами. Это веб-среда, совершенно другой подход.

 

[Apostol]

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

 

[Вурдалак]

В сессии лучше хранить user_id, а не сам объект, иначе ты можешь таскать неактуальный объект и не знать об этом. Чтобы каждый раз не обращаться к базе, надо использовать кеш.

 

[Apostol]

надо использовать кеш.

А можно пример реализации? Или ссылку какую нибудь? Это самое удобное наверное, 1 раз писать в кэш параметры пользователя, в сессию user_id, а потом тянуть параметры по необходимости из кэша, я правильно понимаю?

 

[WMix]

на самом деле можно, незнаю почему ребята против, может обьяснят,...

в зенде писал такое

class User {

	public static function getInstance(){
		try{
			$session = Zend_Registry::get('session');
		}
		catch(Exception $e){
			....
		}
		if($session->user == null || get_class($session->user) !== 'User') {
			$session->user = new User('***');
		}
		return $session->user;

	}
}

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

часто кидали трансляцию в сессию, часто хранил обьект пользователя в сессии...

 

[С.]

Apostol, не слушай Вурдалака, он погорячился. Не надо никакого кеша. В сессии хрнится идентификатор залогиненго юзера. Объект создается по этому ИД при каждом запросе.

WMix, технически можно делать очень многое. Например технически можно на руках по улице ходить, но лучше не надо. Почему? Потому чтто мелочь из карманов выпадывает.

 

[WMix]

ну это же не обьяснение, хочется смысел понять, истину постигнуть..

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

невижу разницы между

$_SESSION['user'] = array(
    'first' => 'Vasia', 'last' => 'Pupkin'
);

или

$_SESSION['user'] = new User( 'Vasia', 'Pupkin');

наоборот вижу преимущество второго способа в том что пользователь описан классом и имеет заранее известное число аргументов...

иначе ты можешь таскать неактуальный объект и не знать об этом.

а то что сам ID неактуален вас не пугает? не тоже ли самое!

 

[С.]

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

Восстановление актуального состяния из хранилища при каждом запросе -- неотъемлема черта веб-приложения (если это только не какое-то узкоспециальное, однопользовательское и уже по сути не веб, а просто клиент-сервер приложение).

 

[Apostol]

Понятно, но например имя пользователя (у юзера нет возможности его менять), можно же тоже в сессию писать?

 

[WMix]

сессия это механизм передачи данных между запросами!

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


и заметь, Вы C сказали

Восстановление актуального состяния из хранилища

сессия это хранилище, ничем не хуже чем база данных!

 

[С.]

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

сессия это механизм передачи данных между запросами!

Вот именно данных, а не неких снэпшотов состояний приложения в виде объектов.

Apostol, сохранять в сессии можно все, что поможет поддерживать работу сеанса, но не то что может изменится между запросами. Имя пользователя вместе с ИД, чтобы съэкономить на запросе к базе? Почему бы и нет, нормально.

 

[WMix]

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

class A{
  privat $instance;

  public __construct(){
   $this->instance = $this;
  }
}

 

[WMix]

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

 

[WMix]

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

по этому поводу вопрос.

возьмем чтонибудь простое но что без сессии реализовать геморойно - корзину покупок.

как хранить правильно карзину Обджектом или всеже масивом тип?
array(product_id => quantity)

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

чтоб дойти до конечного результата, клиетн должен пройти 3, 4 различные формы, и заказчик просил на каждой страничке рисовать корзину покупок...

запишем мы цену в сессию или будем постоянно вычислять ее?

данные из формы будем держать арраем или всеже сделаем обьект типа карт?...

где граница между данными и снапшотами

 

[С.]

Нет однозначного метода организовать корзину. В сессии ли ее писать или сразу в базу (ведь она должна оказаться потом базе так или иначе). В каждом из методов есть свои плюсы и минусы, и есть свобода выбора. Но есть однако и определненная зона, окруженная красными флажками за которые выходить не стоит. По мере разработки должен срабатывать сторожек, например если встал вопрос о сериализации объекта, то в голове включается тревога: "Внимание! Геморр 2-го порядка детектед!"

как хранить правильно карзину Обджектом или всеже масивом тип?
array(product_id => quantity)

В чем какие-то реальные преимущества сохранить этот жалкий объект? Типа общую сумму не надо каждый раз пересчитывать. Серьезно? А вот проблем можно огрести не мало, вплоть до несовместимости в новых версиях PHP.

где граница между данными и снапшотами

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

 

[WMix]

спасибо С. я думаю я изменю свой подход в некоторых местах