Jaké jsou výhody Doctrine 2 proti čistému SQL? rubrika: Programování: PHP
Začetl jsem se trochu do článků o Doctrine 2 od Jana Tichého. Zatím jsem u 5. dílu a stále nechápu, k čemu je Doctrine 2 vlastně dobré. Vždyť je to jen mírně ohnutý starý špatný ActiveRecord. Mám k tomu několik otázek:
- Proč se struktura tabulek čte z dokumentačních komentářů, když mnohem lépe poslouží reflexe na databázi?
- Proč se u dvojice svázaných tabulek pracuje s každou tabulkou samostatně? Není to poněkud zvrácené?
- Proč se tam příšernými oklikami řeší v Doctrine 2 situace, které jsou v SQL na jednom řádku?
- Proč je při používání Doctrine 2 propagováno používání getterů/setterů, když jsou v daném případě zcela zbytečné?
Původně jsem se chtěl naučit Doctrine 2 kvůli tomu, abych si rozšířil obzor, ale nadzvedlo mě to ze židle tak, že si nejsem jist, zda v tom budu pokračovat. Něco málo mě inspirovalo pro dotvoření mého doménového uspořádání servisních modulů (obdoba entit v článku), ale celkově z toho zatím mám pocit, že Doctrine 2 téměř nic nedělá a to co dělá, dělá zbytečně komplikovaně.
Ještě jedna otázka na závěr: Mohou se entity v Doctrine 2 překrývat? Například tím, že se jedna tabulka nachází ve více entitách?
Edit doplnění pro @fprochazka - příklad, který mi nesedí:
// Změníme titulek produktu s ID 123 $product = $em->find('Product', 123); $product->setTitle('Foo bar'); // Odstraníme kategorii s ID 123 $category = $em->find('Category', 123); $em->remove($category); // Všechny změny výše potvrdíme a pošleme do databáze $em->flush();
Jsou zde třídy Product a Category. Proč je to rozděleno? Kategorie je přece součástí produktu č. 123, je to i na stejném vstupním formuláři. Mělo by se to dělat naráz. V mém controlleru by to volání vypadalo následovně:
$product = new Product($post); // $post - data z formuláře předaná přes $_POST $model->update($product); // $product obsahuje všechny informace, které $model (DM) potřebuje k provedení změn
V první řadě si musíš uvědomit, že u Doctrine 2 jde o práci s objekty nikoliv s tabulkami a relačním modelem. Pointou je dovolit ti navrhnout si entity tak jak ti vyhovuje, ideálně tak, aby ti z toho nevznikl anémický model http://www.martinfowler.com/bliki/AnemicDomainModel.html.
Tomuhle je často vytýkáno, že není nikdy možné 100% odstínit datázi od aplikace. Jenže to není pointa. Hlavní pointou doctriny je dělat mapování dat z databáze na objekty, nikoliv schovat databázi.
Vždyť je to jen mírně ohnutý starý špatný ActiveRecord.
ActiveRecord != Data Mapper
- http://www.martinfowler.com/eaaCatalog/activeRecord.html
- http://www.martinfowler.com/eaaCatalog/dataMapper.html
Proč se struktura tabulek čte z dokumentačních komentářů, když mnohem lépe poslouží reflexe na databázi?
- číst strukturu z dokumentačních komentářů není povinné, existují drivery na XML a YAML
- reflexe nad databází funguje do té doby, dokud máš 100% aplikovanou konvenci. Já například vůbec nepíšu názvy sloupců, jak se mají jmenovat v databázi, protože mám zapnutý https://api.kdyby.org/class-Doctrine.ORM.Mapping.UnderscoreNamingStrateg..., tak jsou názvy sloupců předvídatelné, pojmenovávám pouze tabulky v annotaci
@Table(name="xyz")
Proč se u dvojice svázaných tabulek pracuje s každou tabulkou samostatně? Není to poněkud zvrácené?
Můžeš to rozvést? Na příkladu ideálně?
Proč se tam příšernými oklikami řeší v Doctrine 2 situace, které jsou v SQL na jednom řádku?
Můžeš to rozvést?
Proč je při používání Doctrine 2 propagováno používání getterů/setterů, když jsou v daném případě zcela zbytečné?
Protože to je nejsnadnější způsob jak s entitou pracovat. To ovšem neznamená, že to tak musíš nezbytně používat. Já se snažím getterům a setterům vyhýbat, pokud to jde.
Komentáře
- Kit : Používám techniku, která je podobná jak ActiveRecordu, tak i DataMapperu. Podstatným rozdílem je, že jsem z ní vyčlenil perzistentní data do messengerů. Dá se tedy říct, že místo jedné (AR) či dvou vrstev (DM) používám tři vrstvy. Příklad s dvojicí tabulek se pokusím doplnit do úvodního dotazu. — 4.10.2015
Pro zobrazení všech 6 odpovědí se prosím přihlaste:
Nebo se přihlaste jménem a heslem:
Komentáře