FINÁLNÍ VÝPRODEJ KREDITŮ na ITnetwork je tady. Využij poslední šanci a získej až 80 % extra kreditů ZDARMA na náš interaktivní e-learning. Zjisti více:
NOVINKA: Kurz kybernetické bezpečnosti s akreditací MŠMT, nyní již od 0 Kč. Staň se žádaným profesionálem. Zjisti více:
Avatar
Martin Štěpánek
Tvůrce
Avatar
Martin Štěpánek :1.4.2017 13:31

Ahoj,
teď řeším celkem podstatné dilema, jaký z těch dvou vzorů použít. Jaké mají výhody a nevýhody? Jak přesně fungují? Prosím tedy o Vaše názory a případně odkazy na nějaké články, pojednávající o tomto problému (pokud možno prosím v češtině, v angličtině nejsem zase až tak dobrý). :-)
Předem děkuji za pomoc :-)

Odpovědět
1.4.2017 13:31
Všechno jde naprogramovat, chce to jen čas a chuť...
Avatar
TomasGlawaty
Člen
Avatar
Odpovídá na Martin Štěpánek
TomasGlawaty:1.4.2017 21:07

Ahoj,
Při rozhodování je potřeba uvážit velikost projektu.
Při přistupu ve stylu "Active Record" se ti většinou vrací obecný objekt (řádek), či kolekce těchto řádků. Nicméně jedná se o obecnou entitu, která v sobě může obsahovat prakticky jakákoliv data.
Jeden zásadní "problém", který vidím zkusím popsat na příkladu:
V jedné službě si vytáhněš z DB záznam (Active Row) o uživateli, který předáš do metody druhé služby, která třeba kontorluje uživatelovy role. Ta metoda spoléhá na to, že ji předáš instanci Active Row, ale už si nemůže být jistá, co obsahuje. Teoreticky se to dá zavolat s jakoukoliv instanci Active Row, což je logicky špatně.

public function checkAccess(IRow $row) {
    # $row by měl obsahovat údaje o uživateli, avšak lze metodu zavolat s jakoukoliv instancí AR ...
}

Na druhé straně objektové mapování z pravidla vyžaduje deklaraci entit. Tím pádem by daná služba vyžadovala jako parametr entitu uživatele:

public function checkAccess(User $user) {
    # metoda ví, jaký zdroj dat obdrží ...
}

Další věc, která mě napadá je například řešení m:n vazeb. V případě ORM (berme v potaz Doctrine, jelikož se jedná o nejrozšířenější ORM pro PHP) akorát upravíme data v kolekci a pošleme ji do Entity Manageru (EM je správce všech entit, repozitářů atd.). ORM už všechno pak vyřeší za Nás.
V případě Active Record si toto musíme řešit sami (přidání nových vazeb, update stávajících, smázání vazeb) což je docela otrava. Ale to jen tak okrajem, věcí které hrají ve prospěch ORM je více.

Takže v případě Active Record pracujeme s DB na poměrně nízké úrovni (píšeme SQL sami, řešíme sami persistenci dat, vazby ad.).
V případě ORM jsme od těchto rutijních záležitostí oproštěni.

Na větší projekt určitě ORM, osobně už bych nic jiného nevolil na žádný projekt. Avšak nevýhoda je, že pokud nemáš s ORM zkušenosti, tak bude vývoj zezačátku pomalý, jelikož musíš pochopit jak funguje a naučit se procovat s entitami, namísto tabulek. Další věc je výkon, který není tak dobrý jako u prostého AR a v případě špatného nárvhu je to totální zabiják aplikace. I přes to nabízí ORM opravdu mnoho možností a může pomoct vytvořit robustní modelovou vrstvu aplikace.

 
Nahoru Odpovědět
1.4.2017 21:07
Avatar
Martin Štěpánek
Tvůrce
Avatar
Odpovídá na TomasGlawaty
Martin Štěpánek :1.4.2017 21:50

Jo to zrovna vím, ale já se přesněji ptám na návrhový vzor data mapper, ne na třeba Doctrine.
Myslím tím tedy, že nemusím použít Doctrine ani jinou službu a mohu používat vzor data mapper.
Představuji si to tak, že pokud pracuje s Active Record, mám 1 třídu, ve které jsou data i logika s daty. Zatímco u data mapper pracuji s nějakým mapperem/managerem pro logiku, která se provádí na další třídě (entitě). Technicky vzato klidně v tom manageru mohu psát normální SQL.
Snad lze pochopit, co píšu. :-)

Nahoru Odpovědět
1.4.2017 21:50
Všechno jde naprogramovat, chce to jen čas a chuť...
Avatar
TomasGlawaty
Člen
Avatar
Odpovídá na Martin Štěpánek
TomasGlawaty:1.4.2017 22:18

Tady máš přiklad tohoto návrhového vzoru: http://designpatternsphp.readthedocs.io/…/README.html

Samozřejmě je možné vzor používat bez souvislostí na jakémkoliv package. Používám ho také, hlavně ve firmě na starších projektech, kde vůbec chybí nějaká modelová vrstva. Nicméně se dost upíšeš + přiklad co jsem posílal neřeší persistování entit, což může být složitější logika.

Akceptované řešení
+20 Zkušeností
Řešení problému
 
Nahoru Odpovědět
1.4.2017 22:18
Děláme co je v našich silách, aby byly zdejší diskuze co nejkvalitnější. Proto do nich také mohou přispívat pouze registrovaní členové. Pro zapojení do diskuze se přihlas. Pokud ještě nemáš účet, zaregistruj se, je to zdarma.

Zobrazeno 4 zpráv z 4.