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

  1. Martin Fris

    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 ;)

    1. Jiří KneslAutor příspěvku

      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.

  2. Petr Jasník

    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š.

    1. Svaťa Šimara

      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.

      1. vojtechkurka

        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

  3. Petr Jasník

    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.

Napsat komentář

Tato diskuse je již příliš stará, pravděpodobně již vám nikdo neodpoví. Pokud se chcete na něco zeptat, použijte diskusní server Devel.cz

Zdroj: https://www.zdrojak.cz/?p=18528