Přejít k navigační liště

Zdroják » Databáze » Doctrine 2 a NotORM – videotutoriál

Doctrine 2 a NotORM – videotutoriál

Články Databáze, Různé

Seriál o Doctrine 2 od Honzy Tichého vzbuzuje mnohé diskuse. Jedním z vášnivých diskutujících je i autor následujícího textu z rubriky Subjektivně, Jakub Vrána. Rozhodl se na Doctrine 2 podívat kritickým okem a srovnat přístup tohoto ORM řešení s přístupem, který použil ve své knihovně NotORM.

Se zájmem jsem sledoval seriál o Doctrine 2 na serveru Zdroják,
ale některým informacím se mi nechtělo uvěřit. Ne snad, že by byl
seriál špatný, naopak ho považuji za celkem zdařilý, ale nezdál se mi
samotný návrh některých věcí v Doctrine.
A protože je seriál na příklady poměrně chudý, tak jsem se rozhodl
vyzkoušet Doctrine 2 na příkladu vlastním a tím se s knihovnou lépe
seznámit. Svoje pokusy a omyly jsem zaznamenal a vzniklé video vám teď
nabízím ke shlédnutí.

Doctrine 2 – získávání dat

Screencast

Zdrojové kódy

Co se mi na Doctrine 2 nelíbí?

  1. Zhýčkán jednosouborovými minimalizovanými verzemi (jQuery, Nette Framework, Adminer, …) se mi moc nelíbí knihovna čítající 333 souborů.
  2. Část Doctrine závisí na části Symfony,
    která je obsažena i v distribuci. Vlastně by se tomu nedalo nic
    vytknout až do okamžiku, když bych chtěl v projektu použít jinou verzi
    Symfony, než kterou používá Doctrine.
  3. Je potřeba specifikovat adresář a jmenný prostor pro jakési proxy, i když se k ničemu nepoužijí.
  4. Při zadávání informací pomocí anotací je velmi snadné udělat překlep, o kterém se nijak nedozvíme.
  5. Vazební tabulky entit vytvořených v globálním jmenném prostoru postrádají první znaky. Podezíral jsem z toho betaverzi (tutoriál jsem vytvořil před vydáním ostré verze), ale dostalo se to i do finálního vydání.
  6. Pokud chceme s vazbami mezi entitami pracovat obousměrně, tak je také musíme na obou stranách ručně definovat.
  7. Prakticky nikde nás nemusí zajímat skutečné názvy sloupců, které Doctrine 2 generuje, ale v definici indexu je použít musíme.
  8. Sloupec přidaný do entity se při aktualizaci schématu nezařadí na správné místo, ale umístí se až na konec tabulky.
  9. Pro metodu EntityRepository::find existuje šikovná zkratka, pro velmi podobnou metodu EntityRepository::findAll ale tato zkratka neexistuje.
  10. Zcela zásadně mi vadí, že Doctrine 2 pokládá dotaz při každém průchodu cyklem, to je zabiják výkonnosti.
  11. Pokud chceme udělat něco jen maličko složitějšího (třeba setřídit záznamy), tak musíme použít jazyk DQL. Takže pokud si napíšeme kód třeba ve tvaru $em->getRepository('Article')->findBy(array('category' => $category))
    a následně se dozvíme, že bychom články měli ještě podle něčeho
    setřídit, tak musíme tento kód smazat a celý ho přepsat do jazyka DQL.
  12. Při spojení tabulek, které DQL elegantně podporuje, se stejná data přenáší opakovaně. To není tak velký problém jako opakované kladení dotazů v cyklu, ale výkonnosti to také může škodit.
  13. Z mého pohledu se ten úplně největší problém projeví v případě, kdy se rozhodneme do vazební tabulky přidat sloupec
    s nějakou informací. V Doctrine 2 to znamená zahodit velkou část kódu a
    ještě více kódu napsat úplně od začátku. Přitom z pohledu zadavatele
    jde o úplnou maličkost („je to bezva, jen ještě prosím k těm nálepkám u
    článků přidej váhu“).

Můj celkový dojem z Doctrine 2 je bohužel takový, že i když se
knihovna tváří jako vysokoúrovňová a tudíž by měla být robustní, tak
skutečné chování je přesně opačné. Kvůli každé maličkosti se musíme
uchylovat k jazyku DQL (který je velmi podobný SQL), což sice nemusí být
pro řadu programátorů problém, ale rozhodně to má hodně daleko k
vysokoúrovňovému objektovému přístupu, který bych od Doctrine očekával.
Za ještě horší ale považuji to, že vytvořený kód není robustní a i
drobná změna v zadání znamená jeho významné přepsání.

Na Doctrine 2 se mi líbí jedna věc – z definice entit se dá
vygenerovat schéma. A i když tento proces není dokonalý a nepokrývá
všechny možnosti databází, tak v tom spatřuji velkou výhodu hlavně při
nasazování aplikace. Nicméně třeba fakt, že seriál o této funkci
prakticky mlčí, ve mně prohlubuje podezření, že v praxi se tento postup
spíše nepoužívá a schéma se definuje ručně, což je ta nejhorší možná
varianta, protože stejnou práci je potřeba udělat dvakrát a změny se
musí ručně udržovat na dvou místech.

Na autorově blogu si můžete přečíst odpovědi Lead Developera Doctrine na uvedené připomínky.

NotORM – získávání dat

Protože jsem sám autorem knihovny pro práci s daty v databázi, tak jsem z cvičných důvodů vyřešil stejnou úlohu i v knihovně NotORM.

Screencast

Zdrojové kódy

Na NotORM vidím oproti Doctrine 2 tyto zásadní rozdíly:

  1. NotORM se nestará o schéma databáze, což nás nutí definovat strukturu databáze externě, ale zároveň nám dovoluje využít všech možností databázového systému.
  2. NotORM pokládá konstantní počet dotazů, což je z
    pohledu výkonnosti často ten nejlepší přístup, protože se v každém
    průchodu cyklem nepokládá nový dotaz ani se nepřenáší stejná data
    opakovaně.
  3. Kód je velmi snadno modifikovatelný – pokud chceme např. setřídit záznamy, tak jednoduše za $category->article() doplníme ->order("published").
    Stejně tak jsou triviální i změny v návrhu – když se rozhodneme k
    nálepkám článků přidat váhu, tak nemusíme smazat ani jeden znak
    stávajícího kódu.
  4. Pokud z tabulky nepotřebujeme získat všechny sloupce, tak to v
    Doctrine 2 můžeme zajistit pomocí DQL. NotORM nabízí podobný
    mechanismus, kromě toho se ale použité sloupce mohou vybrat také automaticky, což zajistí výkonnostně optimální řešení s využitím minimálního úsilí.

Kromě toho je kód využívající NotORM také podstatně kratší a
přehlednější – velmi jednoduchým způsobem zkrátka vyjadřujeme myšlenku
toho, co chceme s daty provést. Rozhodně se nedá říct, že by bylo zadání
ušito na míru NotORM – jde o klasický demonstrační příklad využívající
vazby 1:N a M:N. U složitějšího příkladu by rozdíl v pohodlnosti práce s
knihovnami vynikl ještě lépe.

Další část

První část videotutoriálu Doctrine 2 se zabývala získáváním dat.
Druhá část bude o jejich ukládání, ve třetí se podíváme na návrh modelu.

Disclaimer: Autor textu je zároveň autorem popisované knihovny NotORM.

Komentáře

Subscribe
Upozornit na
guest
87 Komentářů
Nejstarší
Nejnovější Most Voted
Inline Feedbacks
View all comments
Ondrej

> 8. Sloupec přidaný do entity se při aktualizaci schématu nezařadí na
> správné místo, ale umístí se až na konec tabulky.

Asi kompatibilita s PostgreSQL :) Pg dokaze pridat stlpec iba na koniec tabukly a jedina moznost ako zmenit poradie stlpcov je CTAS (create table as select) a potom drop povodna a rename.

Smokie

Prvy bod aj mne pripada ako blbost a rozmaznanost autora. Koniec koncov to vytyka aj vsetkym ostatnym frameworkom? A co CMS systemy?

Smokie

Hups, reakcia pod nespravny prispevok.

jos

jak člověk zjistí jaký je správný místo pro sloupec?

a proč na tom vůbec záleží?

v6ak

K výkonu: to může udělat DB sama (logicky bude mít sloupce poskládané tak, jak je požadováno, ale skutečné pořadí bude s ohledem na výkon).

v6ak

Nevím, ale mohla by. Do střev jednotlivých DB jsem se nedíval. Ale přesklávávat kvůli výkonu pořadí sloupců mi přijde jako taková mikrooptimalizace, která není hodna toho, aby se tím zabýval koncový programátor.

František Kučera

Zvlášť když ten koncový programátor používá ORM :-)

(tím nechci říct, že ORM je špatné, taky ho někdy používám, ale je to prostě takové kácení lesa – zatímco tyhle optimalizace jsou jen létající třísky – řešit je v takovém případě nemá cenu)

jos

jo ten výkon, to sme tu (v háku) vlastně řešili před časem … jak tu někdo psal, když už to může bejt taková výhoda, tak by se o to měla starat databáze, ne její uživatel

… tak je chci mít vedle sebe i při výpisu z databáze …

to je nějakej špatnej vtip, ne? výpis záleží na pořadí atributů v selectlistu. pro ty kdo používají SELECT * FROM omg.wtf máme širokou škálu sebevražedných prostředků.

Oldis

napriklad pri vypisu pres myphpadmina ze?

hotovson

ha ha ha, a to je chyba databaze, ze phpadmin neumi zmenit poradi sloupcu?

Oldis

proc by poradi menil? je vypisuje tak jak sou

jos

no to je těžkej kalibr mezi argumentama

nechte si svoje pseudoproblémy, mě je to fuk

jc

Na tuhle snusku blbosti uz reagovali autori Doctrine na Twitteru. 1 a 2 jsou naprosty pitomosti, dal uz se mi to cist nechtelo, pripada mi to jako ten samej list jako na tech vasich strankach. Mimochodem Doctrine se taky minifikuje a na symfony vubec nezavisi.

Honza Marek

Odkazy na reakci autorů Doctrine a minifikovanou verzi by nebyly?

Vojtěch Vondra

Taky bych se o ně přihlásil.

Nox

Tady mi přijde, že to záleží na úhlu pohledu jestli to je „část D2 závisí na Symfony“ nebo „pro Symfony má D2 nějakou tu vychytávku navíc“…

adrive

Čo je to Symfony? Pretože Potencier začal písať jednoúčelové komponenty. To že sú v namespace Symfony ešte neznamená, že to závisí na Symfony Frameworku. A to, že je v doctrine Console použitá z potencierových Components, tiež nie je na škodu. Tuším aj YAML parser je použitý potencierov. Ale to mi príde ako, že mi vadí, že s NotORM potrebujem mať v php PDO ak chcem pristupovať k DB.

enumag

Zdravím,

tohle srovnání se mi velmi líbí. Je fakt, že Doctrine mě celkem zklamala, hlavně nutností používat DQL prakticky všude.

Jen když už se píše takovéhle srovnání, co takhle přidat pár slov o NetteDatabase, aby byly vidět výhody/nevýhody této novinky oproti NotORM a Doctrine?

paranoiq

NetteDatabase instanceof NotORM

Tharos

Jednosouborové verze ocení programátor snad jen v momentě, kdy aplikaci potřebuje ručně nahrát někam na FTP. A to je IMHO způsob, který se dneska už u středních projektů (na které se už Doctrine hodí) příliš nepoužívá. Ve všech firmách, se kterými spolupracuji, je deployovací strategie taková, že je mi v důsledku úplně jedno, jestli se nějaká knihovna sestává z jednoho souboru či ze 333.

Výkonnostně je to něco za něco, konkrétně větší paměťové nároky za trochu lepší čas zpracování, takže z tohoto pohledu se IMHO nedá říct, že by minified verze byla něčím kategoricky lepším.

Tohle bych určitě nezmiňoval jako nějaký zásadní nedostatek, já myslím, že Doctrine se v tomhle směru chová úplně standardně.

v6ak

Čemu vlastně vadí nahrávání většího množství souborů přes FTP? Možná to kvůli režii trvá o něco déle, ale to je snad vše.

v6ak

To je sice pravda, ale to je problém většiny updatů.

František Kučera

Totéž jde udělat i s adresářem (který obsahuje klidně stovky souborů), ne?

To spojování do jednoho souboru má IMHO spíš smysl u věcí, které se posílají na klienta (JS, CSS, obrázky), aby se neposílala spousta HTTP dotazů, ale jen jeden a vrátil se jeden velký soubor. U souborů, které zůstávají na serveru, je mi to celkem jedno.

Tharos

No a NotORM má minified verzi? Já jsem ji ještě neviděl a na githubu zdá se také není. Navíc osobně zvládnu rychleji provést dvakrát za sebou přejmenování složky (ve kterých je XYZ souborů), než nahrát celý NotORM. Takže při přejmenovávání složek bude můj deployment Doctrine 2 rychlejší než Tvůj deployment NotORMu. :)

Podle mě je to s tou chvilkou, kdy aplikace nepoběží, zde vyhrocené do extrému (prostě se našel nějaký argument, na kterém se teď lpí). To, že taková chvilka existuje, je přirozené a většinou ji neodstraní ani minified verze. Uvedu příklad: updatuji minified verzi Nette. Nahraji ji na server, ale pak stejně musím ještě promazat cache RobotLoaderu a šablon (zkráceně adresář temp). Zase vznikne zhruba 5 vteřin, kdy se aplikace možná nebude chovat korektně.

Jak se to řeší u kritických systémů?

1. Včas uživatelům oznámím, že tehdy a tehdy dojde ke krátké odstávce systému z technických důvodů.
2. V danou chvíli se nahodí maintenance mód a na pozadí se provedou úpravy.
3. Úpravy se otestují v produkčním prostředí (tenhle krok ve svých úpravách IMHO úplně ignoruješ, což je podstatný nedostatek).
4. Až když je vše OK (a když je vše předem dobře připraveno, jsou dostupné automatizované testy a pdobně, jedná se o sekundy), systém se opět zpřístupní.

Nevěřím, že nějaká minified verze čehokoliv dokáže zjednodušit tento proces.

Naith_cz

Já minified verzi používám raději z důvodu, že při přenosu na ftp se mi občas jeden/několik souborů nepřenese. Pak složitě hledám proč něco nejede…

aaaa

Chce to pouzivat spolehlivy klient, napr. FileZillu.

Honza Marek

Škoda jen, že textový soubor přenesený FileZillou mívá vložen prázdný řádek mezi každé dva řádky, což je autory programu považováno za feature, nikoliv bug.

mirek

linux, simlink. a opravdu, to ze mam 100 tabulek, 2M zaznamu, tak to, ze mam x trid v x souborech je to posledni co me trapi, kvuli tomu mi fakt server swapovat nezacne.

a jsou opravdu jine moznosti jak urychlit app nez komprimovat php do jednoho souboru!!!

František Kučera

Příště bych uvítal videa ve formátu WebM nebo Ogg/Theora, je to takové přátelštější a lépe se to přehrává. (aneb o moderních technologiích nejen psát, ale i je používat)

Martin Malý

Nejsou to videa, jsou to „odklikávací“ videocasty s předdefinovanými pauzami.

František Kučera

aha, mně se to totiž nepodařilo zobrazit vůbec, asi nějak zlobí Flash (mám 10.1.102.65), přitom třeba videa na YouTube nebo jiné flashe většinou fungují.

Filip Procházka

doctrine:
– minimalizované verze
+ proč by nešla doctrine minifikovat? proč by se měla minifikovat?
+ když použiju na deployment git tak je mi jedno jestli má projekt bžilión souborů nebo 10
+ FTP? fuj fuj, málokterý server, který utáhne doctrine má povolené http://ftp...

– Část Doctrine závisí na části Symfony…
+ doctrine má vlastní loader, všechny potřebné třídy jsou prefixované Doctrine/ a při použití loaderu zvlášť pro doctrine a zvlášť pro symfony je to úplně irelevantní

– Při zadávání informací pomocí anotací je velmi snadné udělat překlep, o kterém se nijak nedozvíme.
+ cli orm:validate-schema

– Pokud chceme s vazbami mezi entitami pracovat obousměrně, tak je také musíme na obou stranách ručně definovat.
+ to je nevýhoda, jen pokud v ní někdo nevýhodu chce vidět

– Zcela zásadně mi vadí, že Doctrine 2 pokládá dotaz při každém průchodu cyklem, to je zabiják výkonnosti.
+ DQL

– Pokud chceme udělat něco jen maličko složitějšího, tak musíme použít jazyk DQL…
+ to je nevýhoda? je sice pravda, že by to mohli trochu více optimalizovat, ale DQL imho není těžké a stejně mám všechny definice v modelu a jenom volám funkce.

– Při spojení tabulek, které DQL elegantně podporuje, se stejná data přenáší opakovaně…
+ generuje to klasické SQL, do teď to nikomu nevadilo, dotazy jdou napsat i tak, aby byly více efektivní :)

– Z mého pohledu se ten úplně největší problém projeví v případě, kdy se rozhodneme do vazební tabulky přidat sloupec s nějakou informací…
+ nevidím problém, přidám sloupec do entity, zavolám v cli orm:schema-tool:update a přidám obsluhu do modelů

– generování schéma
+ proboha kdo by to dělal ručně? Myslím si, že Honza na to prostě zapoměl, nemyslím si, že by záměrně nutil čtenáře, aby si sami vytvářeli tabulky. To by byl sadismus :)

notorm:
– Kód je velmi snadno modifikovatelný – pokud chceme např. setřídit záznamy…
+ v doctrine je anotace na výchozí řazení entity, což pokryje velkou část výpisů

– Pokud z tabulky nepotřebujeme získat všechny sloupce, tak to v Doctrine 2 můžeme zajistit pomocí DQL…
+ v doctrine jsou na něco podobného proxy třídy, kterým se předá pouze ID a daty se naplní až při přístupu k jejich vlastnostem, proto taky doctrine doporučuje používat private a protected properties, aby mohla gettery a settery překrývat lazy loadingem

závěr:
Proč se srovnává not-orm (extrémně výkonná knihovnička, na čtení databáze) a pravé ORM (tlustá mrcha co mi dovolí nestarat se o databázi, ale jen o moje objekty)? Na malý webík, který potřebuju mít rychle použiju Nette a možná bych se o podíval na NetteDatabase, ale ještě tak minimálně půl roku budu skeptik. Na velký projekt použiju Nette a Doctrine2, abych se nemusel starat o mapování a další otravné opakující se práce, ale napíšu entity, napíšu služby (a) model a mám vystaráno :)

Nox

+1

+ Kód je snadno modifikovatelný také, kdeco lze nastavit, kdeco lze přidat – drivery, parsery, typy sloupců, funkce DQL, walkery, listenery…

lopata

Naprostý souhlas, to notorm není nic jiného než zapisovat selektování dat pomocí šipeček a závorek a nevím čeho. Kdo nemá rád sql ať si to klidně používá, ale kdo chce objektový mapper pro entity a modely, tak ten použije ORM, ať je to Doctrine nebo něco jiného.

mirek

naprosty souhlas.

clanek jsem vubec nechytl. veci jako ze to ma jiny poradi sloupcu nebo ze to nema jeden 10MB php soubor? a komu to vadi? ja myslel ze jsou tu programatpri, vzdelani lidi a ne banda blondyn…

si prozen zdrojak nejakym tulem at to z toho udela 1 soubor ne? docela chapu ze vec typu notORM se ti vejde do jednoto souboru, ale ja v tom aplikaci psat fakt nechci (pomer zavorek a sipicek v pomeru limitu a wheru je pro me moc velky :), to je zase pro me neco jak opustit namespace a tridy a prstit vsechno do jednoto php i s html s nazvem index.php)

BurgetR

Doctrine konkrétně neznám, možná to je a možná není povedená implementace ORM. Ale připadá mi srandovní tento přístup typu „To je moc velké a složité a náročné na přemýšlení, vždyť to nemůže být tak těžké. Raději to napíšu znovu a lépe“. Těch zmiňovaných 333 souborů v Doctrine asi k něčemu je. To, že v nějakém konkrétním jednoduchém případě vítězí jednodušší řešení je samozřejmě možné. Ale otázka je, jestli to řešení vydrží, i když se projekt rozroste, zkomplikuje, bude potřeba větší úpravy atd. Nezjistíme náhodou, že pořád dokola překopáváme tabulky v databázi a že při každé takové změně musíme přepisovat kusy svého systému? Že by bylo dobré mít schéma někde explicitně sdílené pro celou aplikaci? Nebude problém při přechodu na jinou databázi, která teď ještě neexistuje? Co když už ani nebude relační? Neříkám, že zrovna Doctrine tohle všechno řeší. Ale řeší toho asi mnohem víc.

Tenhle scénář se ostatně opakuje pořád dokola:

– většina programátorů v PHP má za sebou alespoň jeden pokus o napsání vlastního frameworku nebo CMS

– téměř každý začínající tvůrce webů se někdy pokusí o svůj vlastní šablonovací systém

– Java je moloch, pojďme vymyslet něco jednoduššího

– XML je zbytečně složité, já to vymyslím lépe

– ORM je zbytečně složité, já to vymyslím lépe

V čem je problém? Vyřešíte pomocí svého nástroje svůj jednoduchý problém a hned jásáte: „Moje knihovna je desetkrát menší a dělá totéž totéž“. Přijdou další projekty a zjistíte, že tohle chybí, tamto chybí, v horším případě, že tento přístup vám komplikuje práci. Inu co, doplníme, přepíšeme. Po letech zjistíte, že jste naprogramovali už existující řešení:

– Naše šablony by potřebovaly být ještě obecnější, ještě tuto funkci, ještě tamtu … jejda, to už je skoro XSLT

– Do PHP na několikátý pokus konečně přidáme použitelnou podporu tříd, objektů, rozhraní, type hinty a už i namespaces a za chvíli budeme mít skoro Javu

– JSON prý bude mít schémata, namespaces … nezačíná to něco připomínat?

– … problematiku ORM si doplňte sami :-)

Pokud jsem zmínil něčí nenáviděnou nebo oblíbenou technologii ve špatném světle, tak se nezlobte. Technologie nejsou od toho, aby se milovaly nebo nenáviděly, ale jen od toho, aby se pochopily a používaly.

v6ak

„Po letech zjistíte, že jste naprogramovali už existující řešení“
Jen s více chybami, určitou zmateností vývoje a z toho pramenící zátěží zpětné kompatibility nebo přepisování při každé příležitosti.
A v případě PHP bych si rýpnul, že při srovnání s Javou jsou paměťové nároky taky lineární: rozdíl je jen v tom, že u Javy je velká konstanta a malý koeficient lineárního členu, zatímco u PHP to je naopak :P

Škoda, že mi tu nějak zmizelo tlačítko plus. Nějak jsem si moc nezvykl hodnotit, ale občas to udělám a zrovna teď bych chtěl.

Ještě dodám trochu méně skeptický pohled k technologiím:
* Existuje tu proud jednoduchosti a komplexnosti.
* Oba proudy k sobě navzájem směřují. Komplexní technologie dostávají určité zkratky a zjednodušení a jednoduché technologie nabývají komplexnosti.
* Po určité době vývoje bude zařazení mezi jednoduché nebo komplexní jen otázkou historie.
* Jako konzervativnější proud zjednodušování komplexních věcí bych viděl Javu 7 a 8, Lombok a Spring Roo. (Poslední jmenovaný jsem viděl spíše narychlo.)
* Jako pokrokovější proud bych viděl například Scalu a knihovny/frameworky okolo ní.
(Není tu striktní rozdělení mezi konzervativnější a pokrokovější proud – můžete to vidět mírně jinak.)

František Kučera

Ad „Škoda, že mi tu nějak zmizelo tlačítko plus.“

Ono nezmizelo, jen není vidět. Stačí najet na to správné místo a kliknout (pozná se to podle bubliny).

TomBA

100% súhlas

blizzboz

súhlas

v6ak

Na úvod řeknu, že nejsem nějaký zkušený Doctrinista, ale už jsem viděl (z diskusí a článků) prosakující abstrakci:
* U IN prý při předání prázdného pole dojde k chybě. (Prosakují zde vlastnosti SQL, přičemž by nebyl velký problém tuto podmínku přepsat na něco jako false.)
* V případě porušení nějakého omezení (např. duplikace nějaké hodnoty) prý dojde k PDOException.

Na jednu stranu, nemyslím, že se s tím NotORM vypořádá lépe, na druhou stranu, od NotORM bych to neočekával. Od ORM ano. Do nižší vrstvy bych měl vidět obecně nanejvýše v konstruktoru a při nějaké chybě nižší vrstvy, která by běžně neměla nastat (vypadlo spojení s DB). Ne při chybách, které nastat běžně mohou (duplicate constraint violation). Z tohoto pohledu NotORM není vrstva, ale jen curklátko.

Stručně: Řekl bych, že NotORM lépe plní svoji úlohu, ale je to z velké části tím, že není tak abbiciózní.

v6ak

„NotORM se k závislosti na PDO přiznává (v konstruktoru přijímá přímo objekt PDO)“
Obecně to bývá u vrstvy snad jediné místo, kde je možné přiznat svoje závislosti. I ORM se může přiznávat k těmto závislostem v konstrktoru, ale ne při používání. Pak stačí vyměnit implementaci (např. Dibi místo PDO – možná ne nejšťastnější příklad, ale první, co mě napadlo) a zbytek funguje vesele dál.

„víš o nějakém problému, který se v Doctrine řeší pohodlně a v NotORM nejde vyřešit vůbec nebo se řeší krkolomně?“
Určitě se toho najde více, ale u Doctrine je například možné zapouzdřit celkem dobře způsob ukládání dat.

Cechjos

NotORM neumí mapovat řádky db na instance různých tříd (resp. bych toho musel x přepsat, abych toho dosáhl). A nechci to nazývat nutně nevýhodou NotORM, prostě umí jinou věc než D2. (Aneb použiji konkrétní řešení, když ho potřebuji, a naopak. Toto poměřování tudíž z principu nechápu.)

Cechjos

Chtěl jsem naznačit (ač evidentně dosti neandrtálsky), že se může jednat o debatu na téma „proč [ne]použít ORM“ – která už na internetových fórech proběhla nesčetněkrát.

Cechjos

„Oficiální doporučení je vytvářet vlastnosti privátní a přistupovat k nim pomocí getterů a setterů. To je velmi užitečné pro lidi placené za řádky kódu.“

Není nad to umět si udržet odstup. :)

Každopádně co se týče neefektivity tahání dat z DB souhlasím. Snad se to brzo vyřeší:
http://www.doctrine-project.org/jira/browse/DDC-734
http://www.doctrine-project.org/jira/browse/DDC-53

edke

Ak tomu dobre rozumiem, NotORM vzniklo preto, lebo autor nesuhlasi s filozofiou ORM ako takeho (http://www.notorm.com/#why). Preto dost dobre nerozumiem, preco nakoniec svoj produkt ide vobec porovnavat s nejakym inym ORM. Kazdy z nastrojov je IMHO urceny pre inu cielovu skupinu aplikacii.

Jan Kodera

Tj je možnost, že by vývojář definoval schéma za pomocí doctrine a využíval jeho schopnosti kde se to hodí a části, které jsou špatně řešitelné využil NotORM? To by mohlo plnit objekty definované přes doctrine schéma.

Nebo nebude to takhle v Nette?

V Javě se to občas stane, že je třeba trochu ORM pomoci a nevidím v tom velký problém. Teda hlavně v Javě je pro tohle podpora.

Mimochodem, ti z vás které už ta řehole okolo PHP nebaví, zkuste se podívat na Play Framework. Možná zjistíte, že vývoj v Javě není taková pruda jak se říká.

v6ak

„zkuste se podívat na Play Framework. Možná zjistíte, že vývoj v Javě není taková pruda jak se říká.“
Nebo objevíte i jazyk Scala. Taková Java s jednodušší syntaxí. V komunitě Play! celkem populární jazyk.

František Kučera

BTW: napsal jsi v tom Play už něco většího? Je to někde k vidění? Když jsem na tenhle framework koukal, úvodní video je úžasné, všechno vypadá skvěle, ale pořád mi to přišlo takové spíš na hraní… dělat v tom něco pořádného jsem zatím neměl odvahu.

v6ak

Zatím ne. Zvažovali jsme to pro jeden projekt, ale dost možná nakonec pro tuto část použijeme Node.js a já se budu věnovat jiným částem.

U Scaly je situace trošku jiná – je v tom napsán nějaký systém pro Twitter.

Jan Kodera

Ja v tom delam uz vsechny sve projekty. Zkusil jsem to a fakt nemam duvod hledat jiny. Ta efektivita je neuveritelna. Nevim proc ti to prijde na hrani.

David Grudl

Je škoda toho pořadí a volby jednotlivých bodů, zbytečně jdou „chronologicky“, takže každý řeší těch 333 souborů, což je skutečně úplná ptákovina, a k důležitým tématům, jako je efektivita práce s API a především efektivita práce Doctrine s databází, se řada čtenářů asi ani nedostane. Asi by bylo přínosnější rozepsat body 11, 12, 13 do samostatného článku, něco jako byl tento http://zdrojak.root.cz/clanky/phpmyadmin-vs-adminer/

josefrichter

Napsat celej článek (nebo dokonce seriál) o tom, jak něčí výtvor „řeší špatně prakticky vše“ mi přijde zvrácený a… nemoudrý. A myslím, že to nemá na Zdrojáku co dělat. (Podotýkám, že nejsem znalcem ani jednoho řešení a v PHP nedělám.)

Cechjos

…spíše by jim mohl pomoci, kdyby byly zároveň uvedeny odpovědi Beberleiho. (Třeba rozdíl eager/lazy load u bodu deset je dost důležitý.)

josefrichter

Jde o tu formu jakou to prezentuješ. Chybí Ti trochu úcty k cizí práci.

paranoiq

výraz „mít v úctě cizí práci“ považuji za naprosto pomýlený. zavádí k tomu, že by snad člověk měl mít v úctě práci špatnou nebo práci zbytečnou. to je nesmysl. na práci samotné nic úctyhodného není. snaha zaslouží uznání, VÝSLEDEK práce, pokud je dobrý, zaslouží úctu. Jakubův článek je právě o hodnocení tohoto výsledku z jiného pohledu. je celkem věcný a nevyznívá nijak urážlivě nebo hanlivě pro Doctrinu ani její autory. i když jsou některé Jakubovy argumenty malicherné (třeba „333“), někomu mohou přijít důležité, nebo hohou být třeba pomyslnou poslední kapkou při rozhodování jakou technologii nasadit

odborný magazín by si neměl dovolit zveřejňovat pouze názory jedné strany. jsem velmi rád za výborné články Honzy Tichého o Doctrině (přesto že mě některé z nich doslova vyděsily), ale krom kladů je třeba znát i zápory

josefrichter

Nezavádí. Doctrine rozhodně není „špatná nebo zbytečná práce.“

n4u

Neznam dobre ani Doctrine2 ani NotORM, u obou jsem videl jen par slajdu a examplu. NotORM pracuje pouze s databazemi ze? U Doctrine2 jsou to take pouze DB?

Mozna se pletu, tak me pripadne opravte. Pokud ano, tak co jsem povazoval za ORM, jim asi neni. Ale ORM snad neni jen o DB ne?
Ale o modelu, ktery zustava v aplikaci stejny. Stale stejna prace s modelem, nehlede na to z ceho se tahaj data. At je to DB (oracle, postgre, m$), xml nebo nejakej druh cache. Stale pracuji s modelem stejne, jen dle potreby premapuju zdroj.

A jen tak mimochodem jak je to se skalovatelnosti?

Diky za pripadnou odpoved ;)

František Kučera

ORM znamená objektově-relační mapování – jde o propojení objektového světa právě se světem relačních databází. Pokud bys chtěl mapování objektů na např. XML, tak k tomu jsou jiné nástroje (v javě třeba JAXB). Pokud by to mělo být obecné rozhraní nad jakýmkoli úložištěm (databáze, soubory, RAM, síť…), tak na to je takový návrhový vzor ;-) (ORM samo o sobě na to nestačí)

n4u

Jo ahaa, no tak to uz mi pozapadaly kosticky do sebe, diky. Nejak jsem v ty moji prazdny mozkovne smichal ORM s DDD.

Oldis

Existuje tak velky projekt aby na nem melo smysl pouzit doctrine?

Radek

Ano. V podstatě jakmile vývojář zjistí, že bez JOINu v SQL dotazech to už asi nepůjde, měl by současně zvážit, jestli by nebylo lepší použít něco jako ORM. I když třeba ne nutně zrovna Doctrine.

Oldis

napriklad Doctrine pro mne neni natolik pruhledneabych si mohl byt jist tim ze kdyz se ma vytvorit dotaz s inner bude tam a kdyz s left tak tam taky bude. pred lety sem narazil na cakephp, zalibyl se mi z nej model, lec sem narazil na nejaka ta omezeni a pak na adodb a to me odradilo a prinutilo napsat si orm nad vlastnim frameworkem, tedy jeho vrstvou pro praci s databazi. uprednostnil sem pred vseobjimajicim resenim, vlastni reseni na 1500 radkach v jednom souboru, coz uznavam je presne proti vetsine pravidel pro oop, nicmene to funguje, podle mych predstav, a jsem spokojen. samozrejme neresi vse, ale jen to co potrebuji. na frontu ovsem toto nepouzivam, na frontu pouzivam trochu jine dva pristupy, jeden je primi pristup pres dabatazovou vrstvu k datum, tj napisu si presne select na to co chci, a druhej je ze odvodim tridu od vrstvy pohledu, predvyplnim jake chci sloupce, jake podminky, jaka spojeni, a nasledne z pohledu odvozuju dalsi specifictejsi pohledy, na pohled pak vesim filtr, strankovani, razeni, takove ty bezne veci co front potrebuje. toto reseni se mi zatim osvedcilo, mam pocit z toho ze administracni cast je snadno rozsiritelna, a front je vykonny.

BurgetR

S ORM byste se právě neměl starat, jestli tam bude inner nebo left, ale jestli dostanete data, která chcete. Jak si to framework s DB serverem vyřeší už je celkem jeho věc. Když je to chytrý framework, tak může dotazy i optimalizovat podle použitého DB serveru.

Oldis

Coz o to, pouzivani ORM me celkem laka, definovat celou databazi pres xml a nasledne definovat pohledy, nebo si je dynamicky generovat podle pozadavků, ale kdyz tak koukam na doctrine, byl bych radsi kdyby to bylo primo specializovane na mysql, nemelo to v sobe nic navic, bylo to minimalizovane, aby se to nechalo pouzit v jakemkoliv projektu jednim includem, spustilo se to zapsanim jednoho radku a nasledne se to uz jen pouzivalo.

Radek

Málokdo už dnes pochybuje o tom, že má cenu použít nějaký webový framewrok a to i pro velmi malé projekty. Díky vytrvalé evangelizaci mimo jiné i ze strany Zdrojáku, skoro každý chápe, že to přinese minimálně větší bezpečnost, produktivitu a rozšiřitelnost do budoucna.

ORM představuje něco podobného v oblasti přístupu k datům. Cílem je nahradit nízkoúrovňový „ruční“ přístup, který si člověk musí kompletně ohlídat sám, něčím obecnějším, co se snadněji kontroluje a udržuje. Rozdíl je jen v tom, že Doctrine nemá žádného průbojného „věrozvěsta“, který by tohle omílal při každé příležitosti :-)

ad

Musím s autorem souhlasit. Dělám s Doctrine 2 roky a je to hrůza… ale zase bych ORM tak nezatracoval, třeba když to někdy někdo dobře naimplementuje, tak to třeba bude i použitelné…

Honza Marek

Děláš roky s Doctrine 2 (což je nemožné) nebo 2 roky s Doctrine 1, což je úplně jiný projekt než ten, o kterém je článek?

Ruml

Doctrine je docela moloch, chvilku sem si s nim hrál a pocity jsou takový, že to funguje, dá se s tim pracovat, ale je to moc napuchlý a neefektivní (nejspíš sem se s tim jen nenaučil pořádně pracovat).

notORM sem hned taky vyzkoušel (doteď jsem neznal) a nechápu proč ste se vůbec zabýval srovnánim s Doctrine – úplně jinde, úplně o něčem jinym a prakticky žádný zefektivnění PRÁCE nepřináší.

používal sem zend (právě s doctrine) a nějak sem přešel na kohanu, protože se mi zalíbil její minimalistickej přístup, hezká dokumentace a hlavně to, že všechno mi fungovalo hned na poprvý (u zendu bylo docela dost WTF momentů). Vyzkoušel sem ORM v kohaně a prostě stačí – „gets the job DONE“

dělam „menší a středně velký projekty“

Mr.S1lent.cz

Zdravim,

ad 2) Ano, cast Doctrine pouziva Symphony, ale jen pro pristup z terminalu – pro update a dalsi praci s db. Tato vrstva je jeji interni a pri beznem HTTP REQUESTU SE tudiz NEPOUZIVA ;-)

ad 3) Proxy jsou velice dulezite, pro optimalizaci loadu collections. Proto je dobre si v terminalu vygenerovat vsechny proxy rucne po kazdem update databaze (pri zmene vazby).

ad 4) Preklep anotace resi validace a pripadny sql dump v terminalu – zkuseny programator, vi, ze bud ma davat pozor, anebo kopirovat, coz je defacto nejjistejsi ;-)

ad 5) s timto jsem se nesetkal

ad 7) ano nikde nas nemusi zajimat pri vyvoji aplikace (coz je dobre), ale v praxi, pokud clovek pouziva promenne ze slozenych nazvu s „first higher char“, pak vygenerovani nazvu coumns/tables case sensitive muze na linuxovych serverech delat neplechu a je spravne, ze clovek si muze nazvy tabulek a bunek databaze navrhnout sam. Logicky tak oddeli db model (api) a strukturu databaze.

A dal me to nebavi cist uz….

Jinak jsem cetl taky nejakou narazku na vykon – ano, doctrine asi nepouziju na nejaky extra vytizeny eshop, ale pro bezne weby neni rezie vubec znat a kdo chce, tak si nacachuje, co je treba. V doctrine jsme psali i velke projekty a prakticky neni videt rozdil mezi Doctrine a nejakym „not orm db layerem“ :-)

Rekl bych, ze je to jen uboha snaha zviditelnit svoji databazovou knihovnu. Preci jen autori doctrine nejsou zadna becka narozdil od toho, kdo si o doctrine neumi zjistit nebo vyzkouset klicove veci :-)

Miloš Brecher

Jakubův Adminer, Editor a NotORM používám již nějaký ten rok. De facto si už vývoj webových aplikací bez těchto šikovných nástrojů neumím představit. Teď jsem si říkal, že bych se vedle Nette také měl podívat na Symphony + Doctrine, ale tento článek mne zviklal, jestli to má vůbec cenu.

Na dvojce Adminer + Editor je silně inovativní to, že to můžu umístit na web, namodelovat tam nějaké tabulky s testovacími daty a otestovat si SQL dotazy. Klient může paralelně doplňovat některá data a programátor může sledovat návrh databáze – to vše aniž by se musel napsat jediný řádek kódu aplikace.

Další velkou výhodou je velmi snadná instalace Admineru, Editoru i NotOrmu – jednoduše se nahraje jeden soubor.

Kdyby byl možný další rozvoj Admineru a Editoru, byla by to určitě lepší cesta než koncept Doctrine. Přijde mě koncepce definovat strukturu datového modelu + pravidla naklikávacím nástrojem a z nich generovat v aplikaci formuláře logičtější než psát kódem strukturu datového modelu v kódu a odtud generovat databázi i formuláře.

Osobně jsem raději, když se zbytečně moc neabstrahuje a když jsou názvy tabulek a polí v databázi pojmenovány přímo.

Enum a statická analýza kódu

Mám jednu univerzální radu pro začínající programátorty. V učení sice neexistují rychlé zkratky, ovšem tuhle radu můžete snadno začít používat a zrychlit tak tempo učení. Tou tajemnou ingrediencí je statická analýza kódu. Ukážeme si to na příkladu enum.

Pocta C64

Za prvopočátek své programátorské kariéry vděčím počítači Commodore 64. Tehdy jsem genialitu návrhu nemohl docenit. Dnes dokážu lehce nahlédnout pod pokličku. Chtěl bych se o to s vámi podělit a vzdát mu hold.