PHP OOP verzus transakce

Tom

(7 hodnocení)

17. 6. 2011 01:46:26

Zdravim,

chtel bych se zeptat, jak nejlepe resit v OOP objekty a databaze.

OOP uci, ze kazdy objekt reprezentuje jednu entitu a nemaji se michat (analogie k vice tabulkam v sql)

priklad

class zamestnanec {}

class zamestnani {}

Problem nastane, kdyz chceme pridavat rovnou zamestnani i zamestnance. Spravne bychom meli pouzit transakci v sql, aby jsme zajistili datovou integritu, ale to by zase odporovalo OOP, kdy jeden olbjekt muze manipulovat jen se svyma datama...

Tak jak z toho???

jeste aby to bylo zcela jasne

$zamestnanec = new zamestnanec();

$zamestnanec->save("Petr Novak");

$zamestnani = new zamestani();

$zamestnanani->save("Petr Novak","programator");

pokud se mi nepovede ulozit zamestnance, objekty by to podle OOP vubec nemeli vedet, protoze jsou od sebe izolovane

17. 6. 2011 01:46:26

https://webtrh.cz/diskuse/php-oop-verzus-transakce#reply646509

MAHI

(15 hodnocení)

17. 6. 2011 08:19:44

Po pravdě vůbec netuším, co bylo těmito řádky zamýšleno. :-)

Zaměstnání nemusí vědět, "komu patří". Tedy třída Zaměstnání (velké písmeno na začátku je konvence) nemá potřebu vědět, že Petr Novák je programátor.

Zaměstnání může vědět třeba, že se (ono samo) jmenuje programátor, má plat XX tisíc, pracovní dobu tu a tu, trvá tolik a tolik měsíců.

Naopak třída Zaměstnanec o sobě musí vědět, jak se jmenuje: jméno, příjmení, dále třeba rodné číslo, bydliště, číslo občanského průkazu apod.

Jako jeden z atributů v Zaměstnancovi pak může být zaměstnání (tedy atribut $zamestnani třídy Zaměstnání), tento atribut ví vše o sobě a neví nic o zaměstnancovi.

Zaměstnanec se ale může zaměstnání zeptat na jeho soukromé atributy, třeba takto:

Metoda save v Zaměstnanci ani Zaměstnání podle mě nemá, co dělat, pokud tam nedělá něco hodně specifického. Ukládání do databáze by nemělo být ani v jedné z těch dvou tříd.

17. 6. 2011 08:19:44

https://webtrh.cz/diskuse/php-oop-verzus-transakce#reply646508

Radim D.

(7 hodnocení)

17. 6. 2011 09:12:38

$dao = new DataAccessObject();

$zamestnanec = new Zamestnanec("Petr", "Novak");

$zamestnani = new Zamestani("Programator");

$zamestnani->pridejZamestnance($zamestnanec) // nebo $zamestnanec->pridejZamestnani($zamestnani);

$dao->zacniTransakci();

$dao->uloz($zamestnanec);

$dao->uloz($zamestnani);

$dao->potvrdTransakci();

Viz. http://en.wikipedia.org/wiki/Data_access_object

17. 6. 2011 09:12:38

https://webtrh.cz/diskuse/php-oop-verzus-transakce#reply646507

Tom

(7 hodnocení)

17. 6. 2011 09:24:46

Bat, super, tohle mne nenapadlo, ted jen bych rad vedel, zda takhle je "spravne" reseni dle konvenci?

marcus33cz: no, tak to Tvoje reseni je bohuzel mimo. Jeden zamestnanec muze mit totiz vic zamestnani, tak muze byt programator a zahradnik a jak jsem psal spravne by o sobe ty objekty vubec nemeli vedet, to ze mezi nemi existuje relace je veci databaze, ne objektu - i proto v objektech zadne relace nedefinujes

Jeste, formu zapis pls. nereste, ve dve rano byl problem vymyslet priklad :o)

17. 6. 2011 09:24:46

https://webtrh.cz/diskuse/php-oop-verzus-transakce#reply646506

MAHI

(15 hodnocení)

17. 6. 2011 09:46:08

double: Neřekl bych, že moje řešení je mimo. Objekty by o sobě neměly vědět? A vyhovuje ti potom řešení Bata, který k zaměstnání přidává zaměstnance (respektive k zaměstnanci přidává zaměstnání)?

Není to náhodou přesně to, co ti tolik vadí, a přesně to samé?

Když načteš data z databáze (a chceš s nimi pracovat), tak si vytvoříš ty relace mezi objekty - z důvodu optimalizace, aby ses na každou blbost nemusel opakovaně ptát databáze.

Také jsem chtěl naznačit, že uložení (save() nebo uloz()) nemá ani v Zaměstnání ani v Zaměstnanci co dělat. Mělo by totiž být mimo (viz příklad Bata).

Zaměstnanec ani zaměstnání samo o sobě totiž nic do databáze neukládá.

Co se týče více zaměstnání pro jednoho zaměstnance - copak to je problém? Můžeš použít jako atribut pole (array $zamestnani) a přidávat/odebírat prvky. Byl to jen příklad vytvořený bez znalostí souvislostí.

17. 6. 2011 09:46:08

https://webtrh.cz/diskuse/php-oop-verzus-transakce#reply646505

martinzsa

(1 hodnocení)

17. 6. 2011 10:14:13

Napsal double;667098
marcus33cz: no, tak to Tvoje reseni je bohuzel mimo. Jeden zamestnanec muze mit totiz vic zamestnani, tak muze byt programator a zahradnik a jak jsem psal spravne by o sobe ty objekty vubec nemeli vedet, to ze mezi nemi existuje relace je veci databaze, ne objektu - i proto v objektech zadne relace nedefinujes

to co marcus napisal je spravne. to ci ma zamestnanec viacej zamestnani je uz iba vec toho ako si to v triede Zamestanec zadefinujes lebo polozku zamestnanie miesto typu Zamestnanie mozes definovat ako pole Zamestnani a vyriesis tym to co popisujes a vobec neporuris pravidla oop

17. 6. 2011 10:14:13

https://webtrh.cz/diskuse/php-oop-verzus-transakce#reply646504

Tom

(7 hodnocení)

17. 6. 2011 10:20:19

To sice ano, neporusis tim pravidla OOP, ale databaze ano. Vic atributu zkratka nepatri do pole, ale do relace. Jak napriklad polem vyresis, ze zamestannci nepridas neexistujici zamestnani? V apikacni logice tohle nema co delat

to ze metoda save tam nema co delat nemusi byt nutne pravda, trida muze totiz reprezentovat prave objekt v databazi

17. 6. 2011 10:20:19

https://webtrh.cz/diskuse/php-oop-verzus-transakce#reply646503

martinzsa

(1 hodnocení)

17. 6. 2011 10:42:40

To sice ano, neporusis tim pravidla OOP, ale databaze ano

nechapem ake pravidla porusim tym ze pouzijem pre atribut datovy typ pole nejakeho typu...

Vic atributu zkratka nepatri do pole, ale do relace

ano nepatri iba ze tym co som napisal nevytvoris atributy v poli, ale atribut typu pole, a pomocou neho popises vlastne relaciu medzi objektami

Jak napriklad polem vyresis, ze zamestannci nepridas neexistujici zamestnani

vyriesim to rovnako ako aj keby to zamestnanie mal iba jedno, iba s rozdielom ze nenastavujem priamo atribut zamestanie ale pridavam do pola nove...

to ze metoda save tam nema co delat nemusi byt nutne pravda

nie nema to tam co hladat, nato mas iny objekt ktory ti zabezpeci komunikaciu s DB tak ako ti to popisal BAT

17. 6. 2011 10:42:40

https://webtrh.cz/diskuse/php-oop-verzus-transakce#reply646502

Tom

(7 hodnocení)

17. 6. 2011 11:02:44

vyriesim to rovnako ako aj keby to zamestnanie mal iba jedno, iba s rozdielom ze nenastavujem priamo atribut zamestanie ale pridavam do pola nove...

-- takze aplikacni logikou, to jsem psal, ze by se nemelo, na to je prave relacni databaze psana, aby to bylo v jeji rezii. Pokud to nechas na aplikacni, pak to bude: zeptat se, overit, ulozit - coz je zbytecna operace a proste am zustat v rezii databaze

nie nema to tam co hladat, nato mas iny objekt ktory ti zabezpeci komunikaciu s DB tak ako ti to popisal BAT

-- bavime se tu teoreticky, kdo Ti rekl, ze muj objekt neni prave ten co komunikuje s DB? :o) klidne ty dva objekty muzou reprezentovat dve tabulky v DB

---------- Příspěvek doplněn 17.06.2011 v 11:06 ----------

Jeste k:

nechapem ake pravidla porusim tym ze pouzijem pre atribut datovy typ pole nejakeho typu...

-- dokazes si predstavit, ze pises obrovskou aplikaci, kde mas stovky tisic zamestnani? pak je pole blbost, protoze Ti zahlti aplikacni logiku (prochazet pole typu string "programator","ucitel","slapka",..) je proste kapacitne narocne a halvne mi rekni, jak v tech polich resis duplicity? Rekurzi? No to potes, to aby s kazdou tisicovkou zamestnani dokoupil aplikacni server

17. 6. 2011 11:02:44

https://webtrh.cz/diskuse/php-oop-verzus-transakce#reply646501

tyruk

(2 hodnocení)

17. 6. 2011 11:16:40

Napsal double;667137
dokazes si predstavit, ze pises obrovskou aplikaci, kde mas stovky tisic zamestnani? pak je pole blbost, protoze Ti zahlti aplikacni logiku (prochazet pole typu string "programator","ucitel","slapka",..) je proste kapacitne narocne a halvne mi rekni, jak v tech polich resis duplicity? Reverzi? No to potes, to aby s kazdou tisicovkou zamestnani dokoupil aplikacni server

Nezlob se, ale ty jsi evidentne naprosto nepochopil myslenku. Nikdo ti tady nedoporucuje mit pole stringu se stotisici polozkami, nybrz pole objektu typu Zamestnani, ktere patri entite Zamestnanci (Zamestnani.id_zamestnance=Zamestnanec.id). Zkus si neco precist o ORM

17. 6. 2011 11:16:40

https://webtrh.cz/diskuse/php-oop-verzus-transakce#reply646500

martinzsa

(1 hodnocení)

17. 6. 2011 11:22:52

asi sa nechapeme...

uvediem ti priklad v C#

mame DB:

a relaciu medzi tymito dvomi triedami popises takto

-- dokazes si predstavit, ze pises obrovskou aplikaci, kde mas stovky tisic zamestnani? pak je pole blbost, protoze Ti zahlti aplikacni logiku (prochazet pole typu string "programator","ucitel","slapka",..) je proste kapacitne narocne a halvne mi rekni, jak v tech polich resis duplicity? Reverzi? No to potes, to aby s kazdou tisicovkou zamestnani dokoupil aplikacni server

preco by som to mal zahltit? Ved pri vytvoreni instancie si osobu napalnam konkretnymi datami ziskanymi z db tak mi prosim povedz co je na tom kapacitne narocne ?

---------- Příspěvek doplněn 17.06.2011 v 11:24 ----------

tyruk vidim ze aspon ty chapes co sa mu snazim vysvetlit... :)

17. 6. 2011 11:22:52

https://webtrh.cz/diskuse/php-oop-verzus-transakce#reply646499

Tom

(7 hodnocení)

17. 6. 2011 11:28:31

Tyruk:

priklad mas myslim opacne, ale jasne, chapu to. Sice jsme se dostali nekam jinam a tohle je proste spis o tom, ze ORM moc nemusim, zkratka si tohle vyresim radeji na urovni databaze. Nicmene ten puvodni problme byl nekde uplne jinde.

Otazka byla: pokud v jeden cas vznikaji dva nezavisle objekty, jak zajistit jejich integritu? na to jediny odpovedel Bat

resp:

Zamestnanec.id_zamestnani = Zamestnani.id

Pokud v jeden cas nejsi schopny v odlisnych castech systemu (aplikace, DB) zajistit, ze obe entity existuji, musis zahodit obe. I v ORM by jsi prece mel tyhle dve tabulky nezavisle a pak bys tedy musel resit stejnou vec

---------- Příspěvek doplněn 17.06.2011 v 11:35 ----------

martinzsa:

jsme sice v sekci PHP a C# uz si nepamatuji, takze nevim co presne si taha z dtb sam a co necha na programatorovi. Ale kapacitne narocne bude prave Customer.ordes, pokud jich tam budes mit stovky tisic, mas pole, ktere musis resit aplikaci. V php totiz nemuzes rict, ze je nejake pole asociovano jinam.

takze mas Orders (1,2,3,x,5) pokud ukladas Customera a s nim chces rovnou zalozit jeho Orders, pak muzes udelat to, ze mu das Orders = 1,2,3,4,5

Problem je, ze 4 neexistuje, treba chybou DB, a Ty to nemas jak overit. Spravne by jsi tedy nemel dovolit ani ulozeni objektu Customer, protoze obsahuje nevalidni informace

17. 6. 2011 11:28:31

https://webtrh.cz/diskuse/php-oop-verzus-transakce#reply646498

martinzsa

(1 hodnocení)

17. 6. 2011 12:23:15

takze mas Orders (1,2,3,x,5) pokud ukladas Customera a s nim chces rovnou zalozit jeho Orders, pak muzes udelat to, ze mu das Orders = 1,2,3,4,5
Problem je, ze 4 neexistuje, treba chybou DB, a Ty to nemas jak overit. Spravne by jsi tedy nemel dovolit ani ulozeni objektu Customer, protoze obsahuje nevalidni informace

pokial vytvaram nove zaznamy nemam co riesit, pokial pracujem s uz vytvorenymi tak si konkretne riadky pomocou transakcie uzamknem proti zmene a pracuejm dalej... nechapem co stale este riesis...

17. 6. 2011 12:23:15

https://webtrh.cz/diskuse/php-oop-verzus-transakce#reply646497

Jiří Adámek

(20 hodnocení)

17. 6. 2011 12:40:51

Napsal double;667150
takze mas Orders (1,2,3,x,5) pokud ukladas Customera a s nim chces rovnou zalozit jeho Orders, pak muzes udelat to, ze mu das Orders = 1,2,3,4,5
Problem je, ze 4 neexistuje, treba chybou DB, a Ty to nemas jak overit. Spravne by jsi tedy nemel dovolit ani ulozeni objektu Customer, protoze obsahuje nevalidni informace

Tento pripad co popisujes prece nemuze prakticky nastat. Pokud zakladam novy zaznam, pak prvni bude ulozen objekt Zakaznik. Nasledne na nej budou ulozeny jednotlive Objednavky s odkazem na Zakaznika. Pokud by se napriklad obj. 4 z nejakeho duvodu nevytvorila, pak je to jen dilci problem, ktery nema na existenci objektu Zakaznik vliv. Pokud by byly objednavky na sobe zavisle - celek, pak jednoduse provedes ulozeni objednavek v transakci. Ale opet by to nemelo mit vliv na objekt Zakaznik. Ten muze existovat i bez Objednavek. Aspon tak to chapu z hlediska analytiky. Programator jako jakovy nejsem.

17. 6. 2011 12:40:51

https://webtrh.cz/diskuse/php-oop-verzus-transakce#reply646496

martinzsa

(1 hodnocení)

17. 6. 2011 12:45:04

tiez nechapem o co mu vlastne ide... na kazdu otazku dostal odpoved no ani s jednou neni spokojny a vrta sa a hlada chyby tam kde niesu... postupy a principy co tu boli popisane vyuziva ORM, mvc, takmer vsetky framworky a neviem co este a napriek tomu tu mota jedno cez druhe... skor sa mi vidi ze dotycny ma nastudovanu teoriu no v zivote to nerobil inak by sa toto nepytal...

17. 6. 2011 12:45:04

https://webtrh.cz/diskuse/php-oop-verzus-transakce#reply646495