6 komentářů k článku O Doctrine 2 Best Practices:

1. 

   Martin Fris 13.7.2016 v 10:18

   ORM, FP, skalovanie...
   Zaujimavy pohlad na vec z pohladu cloveka, ktory preferuje FP. Neviem ci je vsak korektne takto pisat o ORM, kedze neboli vyzdvihnute realne problemy ORM, iba alternativne moznosti bez pouzitia ORM. Nevadi :)

   K vete o presune logiky z DB do kodu a o skalovani, ktore v Cechach nikto nepotrebuje – tuto nesuhlasim, presun logiky z DB do kodu uz na zaciatku je najlahsia cesta k tomu, aby sa neskor skalovalo, ak to bude potrebne. A ak ta potreba pride, tak databaza zostane uzkym hrdlom a cela aplikacia sa bude moct zahodit a napisat na novo, pripadne bude potrebne celkom velmi zrefaktorovat jadro. Technickemu dlhu nikto neutecie :) Aj na mensom Slovensku sme si mysleli, ze skalovat nebude treba a zrazu mame takmer 2TB velku databazu ;)

   Odpovědět
1. 

   Jiří KneslAutor příspěvku 13.7.2016 v 11:11

   Re: ORM, FP, skalovanie...
   Jasně, já třeba funguji tak, že píšu třeba i pokročilá SQLka, ale nemám logiku vůbec v databázi. Takže třeba mám Common Table Expressions, views, ale nemám stored procedury. Vnímám to jako dobrý kompromis mezi praktičností a čistotou. U megaprojektu by mě to možná nutilo udělat té abstrakce víc.

   Odpovědět
2. 

   Petr Jasník 13.7.2016 v 10:29

   Díky za jiný pohled na věc, ale zdá se mi, že si trochu zapomněl, že se to týká pouze Doctrine ORM.

   Doporučuju záznam celé přednášky, který je přínosnější než samotné slajdy
   https://vimeo.com/channels/phpday/134178140

   The database is just saving things

   Doctrine ORM se snaží být nezávislá na typu DB (MySQL, Postgre, atd..). Doctrine ORM se snaží být „database agnostic“. Pokud využiješ naplno potenciál dané DB (triggery, views, procedury), přijdeš o možnost, bez úpravy kódu, přejít na jinou DB. Jednoduše proto, že daná DB např. triggery vůbec nepodporuje.
   Jasně, v reálném světe se moc často nestává, že se přechází na jinou DB. Doctrine umožňuje jednoduché přepnutí DB, proto je databáze jako hloupé uložiště „best practice“. Možnost úpravou jednoho řádku přepnout aplikaci z MySQL na SQLite se někdy hodí.

   Entities should work without db

   Závislostí na DB je zde myšleno např. generování ID entity pomocí auto_increment indexu v DB, kdy entita nemá žádné ID dokud neproběhne uložení do databáze a nelze s ní tak dále pracovat. Generovat UUID v konstruktoru entity místo použití auto_increment je tedy vhodnější a není potřeba komunikace s DB.

   Design entities first

   Řekl bych, že toto spíš vychází z toho jak celá Doctrine funguje. Jednoduše si nadefinuješ entity a jedním příkazem vytvoříš celou databázi. Databáze je díky tomu pouhým implementačním detailem a je jedno jakou nakonec zvolíš (viz. předchozí bod).

   Avoid soft deletes

   V tomhle naprosto souhlasím, oba způsoby jsou vhodné na něco jiného a většinou je implementace Event sourcingu o tolik složitější, že se od toho prostě upustí.

   Keep collections hidden in your entities

   Zase to vychází z toho, jakým způsobem funguje celé mapování. Kolekce si klidně z entit vracet můžeš, ale pouze jako nový objekt nebo jako immutabilní. V dokumentaci se doporučuje toArrray() a je to jen kvůli tomu, že doctrine kolekce nejsou immutabilní a jakýkoliv vnější kód může kolekci jakkoliv měnit (může se stát nevalidní). Změny se pak při uložení entity, z které byla kolekce předána projeví i v DB (pokud není namapováno jinak). Entita tak nemá žádnou kontrolu nad stavem kolekce, kterou si předal ven.
   Pokud potřebuješ upravovat kolekci vně entity, můžeš ji po úpravě vždy entitě nastavit setterem.

   Všechno jsou to doporučení a né dogma. Každé doporučení má své „ale“ a vždy bude záviset na konkrétním případu. Tvůj způsob použití může být „krátký, udržovatelný, velmi výkonný“, ale cílem těchto best practices není „krátký, udržovatelný, velmi výkonný“ kód, ale co nejvíc bezproblémové a pro většinu případu nejjednodušší použití celé Doctrine. Best practices pro „krátký, udržovatelný, velmi výkonný“ kód by určitě vypadaly jinak a asi obsahovaly hodně z toho co píšeš.

   Odpovědět
1. 

   Svaťa Šimara 13.7.2016 v 11:17

   Re: The database is just saving things

   Možnost úpravou jednoho řádku přepnout aplikaci z MySQL na SQLite se někdy hodí.

   Zcela souhlasím, pro normální provoz používáme MySQL, systémové testy pouštíme kvůli rychlosti na SQLite a začínáme pošilhávat po PostgreSQL (kvůli práci s jsony). Díky Doctrine tento přechod nejen bude možný, ale bude i zdarma.

   Odpovědět
1. 

   vojtechkurka 13.7.2016 ve 20:47

   Re: The database is just saving things
   Pouzivat v produkci MySQL a na testy SQLite mi neprijde dlouhodobe jako dobrej napad, ty testy pak maji polovicni hodnotu. Lepsi je zlepsit nastaveni DB pro testy, nebo jejich spousteni paralelizovat. Ziskate tak i spolehlive testy pro upgrady DB na novejsi verze.
   A jestli je pro vas nejvetsi motivace pro prechod na Postgres JSON, zkuste JSON implementaci v MySQL 5.7

   Odpovědět
3. 

   Petr Jasník 13.7.2016 ve 15:06

   začínáme pošilhávat po PostgreSQL (kvůli práci s jsony)

   Z jaké verze MySQL přechod zvažujete? V MySQL 5.7 už nativní podpora pro JSON je.

   Odpovědět