Hali!
Meg azelott hogy belemelyedtem volna php oop be, merul fel bennem a kerdes: webes alkalmazas eseten egy phpscript egy http keres eseten fut le, es utanna a letrejott valtozok, objektumok is es barmik ugyebar "meghalnak". minden keres esten ujra letre kell hozni, inicializalni, stb az objektumokat? ha ket keres kozt nem maradnak meg az allapotok, ujra fel kell epiteni a kivant strukturakat, ami sok eroforrast vihet el. Ha ez igy van, talan nem is nagyon erdemes oopben webalkalmazast programozni(mondjuk lib irasara max)
Szoval hogy is mukodik ez?
Zsolt
- 1696 megtekintés
Hozzászólások
hint: serialize/unserialize, vagy session_register a baratod
- A hozzászóláshoz be kell jelentkezni
latom, ez kezeli a problemat, de a manual szerint
This function has been DEPRECATED as of PHP 5.3.0 and REMOVED as of PHP 6.0.0
es nem emlit helyette mas modszert.
talan pont a serialize lenne az?
A php nyujt valami valtozot, tarat a programok szamara az allapot megtartasara(nyilvan egy sessionre nezve) vagy erre haszaljon kizarolag adatbazist a programozo?
zsolt
- A hozzászóláshoz be kell jelentkezni
Utmutatas volt, a session_register-t a $_SESSION valtozon keresztul tudod hasznalni, ami nem deprecated.
- A hozzászóláshoz be kell jelentkezni
A session kezelés megmarad csak a register eljárás változik meg/tűnik el:
valahogy így fog kinézni
session_start();
$_SESSION["valtozo"] = "session valtozo vagyok";
- A hozzászóláshoz be kell jelentkezni
viszont arra vigyazz hogy resource tipust nem tudsz serializalni. A tobbivel mukodik. Objektumok serializalasa soran pedig csak az allapot fog belekerulni
- A hozzászóláshoz be kell jelentkezni
Koszi, tudom. Nem en kertem tanacsot :)
- A hozzászóláshoz be kell jelentkezni
tudom, de a te hozzaszolasod folytatasakent szantam, nem valaszkent igazabol
- A hozzászóláshoz be kell jelentkezni
serialize, haha :)
PHP-sek szerint külön jó, hogy \0 -okat rak egy string közepére, ha objectet serializálsz. (És egyébként tényleg jó, míg nem akarom egy pg_escape()-n átereszteni, mert az nem a PHP belső string struktúráját használja, hanem rendesen const char * -t.)
----------------
Lvl86 Troll
- A hozzászóláshoz be kell jelentkezni
amig ugyanazt kapom vissza belole mint amit beleraktam, engem aztan baromira nemerdekel hogy mit csinal a hatterben vele a ketto kozott
- A hozzászóláshoz be kell jelentkezni
...csak ne akard közben adatbázisba tenni
- A hozzászóláshoz be kell jelentkezni
Miert akarna egy objektumot adatbaziba tenni?
- A hozzászóláshoz be kell jelentkezni
miért ne? Pl egy session-t nem file-ban akarsz tárolni hanem adatbázisban, vagy egy rendelést, ahol garantált, hogy az osztályok szerkezete nem változik, vagy csak bővül, miért ne mentenéd le a "kosarat" ami termékeket tartalamaz, meg áfakulcsot, meg árakat, meg házhozszállítást, meg egy csomó dolgot, amik egymásba ágyazott osztályokból állnak, egyszerűbb serializálva tárolni a kosarat, mintsem mindent külön mezőkben és táblákban letárolni. Amúgy számtalan példát lehetne hozni.
- A hozzászóláshoz be kell jelentkezni
Ez egy brutalis tervezesi hiba lenne :)
- A hozzászóláshoz be kell jelentkezni
Hát én már találkoztam ilyennel, nem én találtam ki, és amúgy tervezési hiba (erről nem szeretnék vitát nyitni, ugyanis mint írtam, addig működik, amíg az osztályok változatalnok, vagy csak bővülnek, egyébként sok problémát okozhat) ide-oda működik. De hogy a példától elszakadjunk én csak arra reagáltam, hogy miért ne akarna szerializált objektumot adatbázisba menteni, hisz a szerializáció pont arra van, hogy hordozható legyen egy osztály az állapotával együtt.
- A hozzászóláshoz be kell jelentkezni
Viszont meg tudsz írni dolgokat általánosra, egyszerűen kódolhatóra, hordozható kódúra és ha mindezt normálisan csinálod, fele annyi idő alatt végzel. A megspórolt fejlesztői erőforrás árából meg 5x annyi vasat pakolsz alá, mint amennyi valaha is szükséges lehet.
Jelenleg a mérnökóra vs. vas témakörben a legtöbb projekt esetén a vas áll nyerésre.
OOP nem arra van, hogy überhatékony, szanaszét optimalizált programot írjál benne (ez nem jelenti azt, hogy nem lehet gyors programot írni), hanem arra, hogy hatékonyan fejlessz.
----------------
Lvl86 Troll
- A hozzászóláshoz be kell jelentkezni
Azért illene nem bloatwareben gondolkodni meg 5x annyi vasban. :D Mert az üzemeltetés drágább lesz, akárhogy nézed. :)
- A hozzászóláshoz be kell jelentkezni
Legyen egy projekt, legyen mondjuk 15M fejlesztési költsége. Kellene alá mondjuk 400K-ért vas + 160K-nyi hufnyi villany* + net üzemeltetés költsége. Megoldod a projektet 12M-nyi mérnökórából, cserébe kell alá 800K-ért vas + 360K-nyi villany + üzemeltetés költsége ugyanúgy.
Melyik éri meg jobban?
Konstans 200/400W fogyasztással számoltam, 50 huf KWh-val, 3 évre.
----------------
Lvl86 Troll
- A hozzászóláshoz be kell jelentkezni
15M-s projekt ala nem entry level szervert teszel és rögtön nem ilyen occó a duplázás. A klima+egyebet ha 3 évre számolod, akkor bőven kilépsz a 15M-ból.
- A hozzászóláshoz be kell jelentkezni
Nehogy már... Pl. viszonylag kevés alkalmazottat foglalkoztató cég (legyen mondjuk 10-50) belső intranetes rendszere alá mit raknál? Szerintem nem a projekt ára határozza meg a fejlesztett alkalmazás gépigényét. :)
15M alatt a fejlesztés költségeit értettem, ha nem lett volna egyértelmű, a hardver és az üzemeltetés költségeit külön számoltam.
A 400k-ba meg szerintem belefér egy lassabb fajta 2xQuad-s Xeon, 8G ram, sw raides SATA RAID10, ami azért elég sok dologra elég, ha értelmesen vannak összerakva a dolgok. (Jó, nem lesz brand gép, tény).
-
Más: viszont ameddig a legtöbb "programozó" hallani se akar az SQL-ről és bottal se akarja piszkálni, nemhogy akár 5 percet is gondolkodni rajta, hogy hogyan is lehetne megoldani az adott feladatot SQL-ben, addig nem a PHP OOP-je lesz a lassú, hanem az adatbázis lesz legyilkolva az elcseszett Querykkel.
----------------
Lvl86 Troll
- A hozzászóláshoz be kell jelentkezni
400-ba sokminden belefér, viszont 10-50 alkalmazottnál nem fér bele hogy táphiba miatt órákat álljon a történet. A mai vasaknál (normális alkalmazásokat nézve persze, mert mint tudjuk az igazán elborult fejlesztőnek nem okoz gondot egy 150 gépes cluster fektetése sem, lásd az SQL-es példádat) nincs igazi teljesítmény probléma.
Irodai installra a redunáns tápot és UPS-t én mindenképp eröltetném, illetve a klimázott helyiséget. Azt is tudom, hogy nem halnak sorra és mp-enként a szerver tápok, de jobb a béke. Persze ha megoldás a sima polcra tett tartalék táp, mert a helyi csere megoldott, akkor megfelelő lehet az is. Egyébként szerintem ilyenkor születnek a kb. negyedig megrakott, de redundáns táppal vett izom vasak. :)
- A hozzászóláshoz be kell jelentkezni
Jó, akkor legyen 600-1,2M a differencia. Viszont még így is ott tartunk, hogy ~2,4M-l olcsóbban megúszod a fentebbi példát figyelembe véve.
"Irodai installra a redunáns tápot és UPS-t én mindenképp eröltetném, illetve a klimázott helyiséget."
Ezek a költségek egyébként is meglennének és többnyire amúgy is rendelkezésre állnak. Ha meg nem irodai, akkor meg általában úgy is hostingba megy, és ugyanott vagyunk, hogy villany.
Szóval, akárhogy csűröd-csavarod, nem a vas a drága a projektek 99%-ánál. Arról nem is beszélve, hogy nem ritka, hogy már meglévő vasra raknak rá projekteket, mert még mindig elfér.
----------------
Lvl86 Troll
- A hozzászóláshoz be kell jelentkezni
Az OOPvel onmagaban en is tisztaban vagyok, ellenben nem gondolom azt sem, hogy ubermega megoldas. Megintcsak, ahogy mondod "_ha_ mindezt normálisan csinálod" akkor is lehet altalanos, egyszeru es hordozhato kodot irni OO nelkul is. Az OO nem ebben segit(no jo az egyszerusegben egy kicsit igen:)
zsolt
- A hozzászóláshoz be kell jelentkezni
oo szemlélet nélkül moduláris, megfelelően testreszabható és továbbfejleszthető keretrendszert összehozni azért elég nehéz
- A hozzászóláshoz be kell jelentkezni
érdemes OO -t használni ezzel együtt. könnyebb fejleszteni, karbantartani, átlátni. hacsak nem nagyon spéci környezetbe kell, akkor ezért érdemes beáldozni a picit lassabb végrehajtást. később persze lehet tuningolni a végrehajtási időkön, pl cache-elés, fcgi, stb - ezek sajátosságait pedig egy jól tervezett keretrendszer képes elrejteni
- A hozzászóláshoz be kell jelentkezni
A PHP alapvetően nem egy ojjektumos nyelv, csak később került bele egyfajta - egyébként azóta is fejlődő - objektum és osztály kezelés. A teljesen privát és viszonylag amatőr/hobbi PHP tudásommal olyanokat érdemes OO szemlélettel kezelni amik pl. egy adatbázis réteg kezelése, egy felhasználó/session kezelés vagy más olyan aminél jól definiált egységet lehet kezelni (akár egy webáruházban ilyen egy megrendelés vagy ha több domaint kezelsz egy kóddal akkor a domain tulajdonságai és a PHP futások között pedig SQL-be lehet menteni amit kell) és ezek tényleg többször jól felhasználóhatóak. Ezen felül talán inkább bonyolít és tényleg emeli az erőforrás igényt, tehát a feladat specifikus dolgokat érdemes simán lekódolni.
- A hozzászóláshoz be kell jelentkezni
Talán egy dolgot lefelejtettél, akkor is érdemes oop-ban programozni, ha másokkal dolgozol együtt, vagy ha a te kódhoz másnak is hozzá kell nyúlnia, mert az "egységbe zárások" lévén könyebb átlátni/használni mások kódját (amennyiben normális _meg_tervezett oop-ről beszélünk).
- A hozzászóláshoz be kell jelentkezni
Igen ez a másik eset. :)
- A hozzászóláshoz be kell jelentkezni
Igen, a strukturak felepulnek minden egyes kereskor HA nincs betoltve megfelelo PHP-gyorsito, VAGY folyamatos futast / cache-t biztosito modul. Utobbi problemaja, hogy a PHP-t tenyleg request-lifetime -ra talaltak ki, es bizony hajlamos leakelni, ami addig nem gond, amig felepul-lefut-eltunik, de folyamatos futasnal megeheti a memoriat. Persze lehet hogy mar nagyon bebugfixaltak.
Aztanmeg. A PHP ojjektumai valojaban hashek, legalabbis a tulajdonsagkezelesuk mindenkeppen az, ezt jo figyelembe venni ilyen gondolatoknal.
Alapvetoen a legtobb webalkalmazas alkalmaz valamilyen cache rendszert, ez keretrendszer-fuggoen vagy beepitett, vagy nem, vagy kulon kell bekapcsolni, vagy nem, raadasul ez nem csak PHP-ra igaz, de igy van ez mashol is.
A cel az, hogy minel kevesebb kod fusson le.
A "tiszta" OOP program, azaz hogy mindenki vegyesen tartalmaz tulajdonsagokat meg fuggvenyeket, nem igazan divat errefele sem.
PHP-s OOP webframeworkok kozul a 3 legnagyobb talan a zend, a symfony es a cakephp, egyiket se kotelezo hasznalni, peldanak jok.
Miutan az ojjektumok hashek, tipusellenorzes pedig csak hintingnel van, neha erdemes elgondolkozni esetleg, egy entitast nem kenyelmesebb-e asszociativ tombkent abrazolni, ill. nem szabad visszariadni tole, merthogy eleg hasonlo egy entitasobjektumhoz.
Amugy hajra.
- A hozzászóláshoz be kell jelentkezni
Elmondom, hogy mi a helyzet weben a kérések közt is élő objektumokkal.
Először is van a perl/python/java megoldás, ahol is az objektumok élve maradnak. Jó dolog, de vannak hibái is. Pl, hogy a munkameneteknek ragadósaknak kell lenniük, tehát ha egy munkamenet elindult az egyik kiszolgálón, akkor az ott is marad a megnyitott objektumokkal együtt. Kevésbé biztonságos, és kevésbé kiegyenlített, mint a teljesen elosztott fürt, de szépen működik. Persze lehetne távoli objektuméléréssel is csinálni, de tudtommal ez nem divat. Hátránya még, hogy a munkamenet lezárásáig foglalja a memóriát, vagy jobb esetben a cserehelyet.
A php mást csinál, ő egy vagy több kiszolgálót tart fenn munkamenet szervernek. A munkamenet adatokat elvileg kiírja file-ba, de gyakorlatilag nem biztos, főleg, ha meg van pakolva memóriával a gép. Jól felépített rendszer esetén jobbára a régi, és nagyobb eséllyel holt munkamenetek íródnak ki fájlba.
Végső soron a php munkameneti megoldása sem kell hogy lényegesen lassabb legyen, mint az élő objektumok, hiszen mindkét esetben először memóriába, annak fogytán a háttértárba kerülnek a munkameneti adatok.
- A hozzászóláshoz be kell jelentkezni