Diskuze: Active record vs Data mapper
V předchozím kvízu, Online test znalostí PHP, jsme si ověřili nabyté zkušenosti z kurzu.
Zobrazeno 4 zpráv z 4.
//= Settings::TRACKING_CODE_B ?> //= Settings::TRACKING_CODE ?>
V předchozím kvízu, Online test znalostí PHP, jsme si ověřili nabyté zkušenosti z kurzu.
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.
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.
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.
Zobrazeno 4 zpráv z 4.