Witam

Zastanawiam sie nad taka sprawa.

Tworzenie obiekty w php odbywa sie zawsze podczas odswiezenie strony.

A co jesli zastosujemy taki mechanizm.
1. Tworze obiekt
2. Serializuje go
3. Podstawiam zserializowane dane pod zmienna sesyjna.

A na poczatku skrypty zawsze robie:
1. Jezeli istnieje zmienna sesyjna, odserializowuje dane
2. Mam znowy moj obiekt

Czyli w takim wypadku obiekt tworzony jest tylko raz a kiedy go chce usunac to ja sam o tym decyduje. Co za tym idzie - mam pelne podejscie OOP - mam do dyspozycji obiekt kiedy chce oraz zgromadzone w nim dane (np. z bazy danych) - co zmniejsza ilosc odwolan i pobran z bazy.

Jest to moim zdaniem super sprawa, ale ....
O tu nasuwaja mi sie pytania
Czy warto uzywac sesji do trzymanai obiektu
Jesli ktos ma zablokowane cookies i prywatnosc na maxa - wszystko nie ma sesnu bo nie dziala ...

Jakie jest wasze podejscie do tej sprawy ?

i co... pobrales 100 newsow i trzymasz je wszystkie w sesji tylko po to by potem gdzies tam moze zaoszczedzic na jednym zapytaniu ?
jak dla mnie nie ma to glebszego sensu.

optymalizacja tak! ale nie na sile ;]

no na przyklad. :-)
no ale co jest strasznie zlego jezeli w obiekcie typu contener trzymam teblice wlasnie ze 100 newsami ale tylko niezbedne dane jak id, title, a dopiero bo wybraniu jakiegos tworze obiekt news.

W OOP w Javie, C++, Delphi to jest normalne ze mozna trzymac nawet bardziej zlozone struktury - drzewa, lista a w nich inne "nawet" ciezsze obiekty.

W JSP przydziela sie czas zycie obiekty do sesji itd..
W php jakos wciaz nie moge sie przekonac do OOP jezeli obiekt jest zawsze tworzony na poczatku i zawsze trzeba go od nowa inicjowac.

Wiec czy trzymanie 100 newsow w obiekcie - w tablicyt - jest bardzo obciazajace ?

Czekam na dalsze sugestie.

jeśłi chodzi trzymanie 100 newsów w sessji - jest tu zupełnie zbędne.
Dlaczego? Ponieważ sessja jest tworzona dla każdego użytkownika osobno, więc w ten sposób przechowywałyś na dysku dziesiatki instancji tego samego obiektu.

Jeśli jednak zależąłoby Ci na optymalizacji tego rozwiązania, to można przeciez zserializować cały obiekt, i zapisać go na dysku serwera, w postaci pliku.
Potem każdy z użytkowników będzie korzystał z tej samej instancji obiektu, ważne tylko jest to, by przed odtworzniem zserializowanego obiektu zaincludować klasę z odpowiednim kodem.

Bo jakiego wafla to robić ?

@adamos - trzeba pamiętać o jednej rożnicy - php nie ma 512 MB RAM-u jak appsy dla Delphi czy C++. Po drugie typowy skrypt w php wykonuje się nie więcej niż załozmy 5 sekund(aplikacja może chodzić np. 5 godzin) - serializajca obiektowów jest nie potrzebna. Na tym podłożu toczy się dyskusja jak powinno wyglądać MVC dla php - chodzi mi rożnego rodzaju niuanse tejhj architektury dla php. php jest podobny skladnią do C++ ale należy pamiętać, że służy do innych celów i na pierwszy rzut oka podobne rozwiązania nasladujace inne jezyki nie zdaja egzaminu w php.

Jak słusznie zauważył DeyV, sesja jest na użytkownika. Nawet w Javie nikt nie będzie wkładał 100 newsów do sesji. Trzymanie gdzieś w aplikacji ujdzie. Kurcze, masz EJB, masz ORM. No problem. Ale to przecież nie ma nic wspólnego z sesją.

I co tu ma do rzeczy Delphi lub C++?! Aplikacja desktopowa nie ma sesji...

Adams, zdecyduj się, o co Ci chodzi:

Tak.

Nie.
Co nie zmienia faktu, że pakowanie newsów do sesji jest głupotą, i nijak się ma do Twoich pytań.

Ostatnio myślałem nad serwerem aplikacji i co do życia obiektów to można je wrzucić na serwer aplikacji, albo jeszcze lepiej, napisać session handler który łaczy się z serwerem aplikacji i tam trzyma te obiekty.

bela - ale to już ktoś wymyślił...
Robert Janeczek -> Framework Hive -> http://hive.segfault.pl/

DeyV - wiem ostatnio wlasnie się przygladalem się Hive i cześć, rzeczy mi sie nie podoba/rozwiązałbym inaczej. Pozatym jak się troche zagłebić w ten temat to powstało co najmniej kilkanaście application serwerów dla php. Wystarczy wpisać "php application server" do googla

Dyskuja na sitepoint o 'kontenerze servletow dla php'

BTW Najbardziej w Hive wkurza mnie to, że jest zależny od PEARa, sprobowałem go jakos zainstalować ale nie dało rady ( chyba za mało cierpliwy czasem jestem )

Witam, widze ze ciagniecie topic ktory takze mnie zastanawia. Zrozumialem z tego ze trzymanie zbyt wielu obiektow w sesji nie ma kompletnie sensu, a co naprzyklad jezeli mam Sesje z koszykiem na zakupy, ktora przechowuje obiekt ktory wlasnie dodalem do koszyka. Zakladajac ze uzytkownik nie kupi 100 produktow tylko 1-10 czy trzymanie informacji o tym produkcie w sesji jest zoptymalizowanym podejsciem czy lepiej wywolywac dane z bazy. Pod koniec zakupow i tak trzeba z baza sie pewnie polaczyc aby sprawdzic raz jeszczce czy produkt jest w magazynie itp.
Co myslicie ?


noob.

No właśnie, pod koniec, a nie podczas przemieszczania się po sklepie internetowym. Zaśmiecasz niepotrzebnie tak drogocenną pamięć podręczną. Przy mniejszych aplikacjach to jak chcesz możesz trzymać nawet i całą bazę danych, nawet przy 1000 odwiedzin dziennie nic się nie powinno złego dziać, ale co się dzieje przy 50000 odwiedzinach dziennie ? wszystko trzymasz sobie w powiedzmy sesjach i wyciągasz te dane z ciasteczek non stop ? za każdym odświeżeniem strony ?
Im więcej trzymasz w zmiennych, tablicach czy obiektach tym bardziej obciążasz aplikację !

Brawo za odgrzanie 6 letniego kotleta.

Co do koszyka. Nie wystarczą Ci w sesji identyfikatory produktów? Czy pobranie ceny i nazwy produktu to tak wielkie wyzwanie dla bazy?

No wlasnie tak robie,za pomoca id czerpie informacje. Moj nauczyciel jednak chcial abysmy trzymali obiekty w sesjii lecz mi czyms to smierdzialo dlatego pytam. Niestety nie potrafie zrobic jakiegos testu z pomiarem obciazenia bd przy takiej funckji jak(np koszyk) i porownac to z wynikami obciazonej sesji.Dlatego wiec pytam co bardziej jest obciazajace obiekty w sesji czy zapytania dla swiata php/mysql.

Wariant z bazą danych to:
1. Odczytanie danych z bazy.
2. Utworzenie obiektów na podstawie danych z bazy.
-- Obiekt gotowy do użycia

Nawiązanie połączenia sobie darujemy bo i tak jest to zawsze wykonywane.

Wariant z sesją to:
1. Deserializacja obiektów
-- Obiekt gotowy do użycia
2. Serializacja obiektów

Odczyt i zapis danych też sobie darujemy bo to zawsze się robi (a różnica w zapisie 1 KiB, a 10 KiB nie jest istotna - chociaż to zależy od tego gdzie przechowujesz tą sesję).

No, to jak już wiesz z czym wiążą się dwa rozwiązania sprawdzenie które działa szybciej w przypadku 100 000 bazy produktów nie powinno być problematyczne?