Dibi or Doctrine2 or Nette Database?

Srovnání:

• Dibi je stabilní, odbugovaná, ale „stará“, nemá tak pěkné api
• Nette\Database má výrazně méně bugů než-li měla, resp už se může na projektech normálně používat krásný API
• Doctrine: Výrazně složitější než předchozí dvě, není to prostá obálka nad databází, takže na to konto může řešit mnohem pokročilejší věci než předchozí dvě

Vyber jsi podle sebe

Osobně jsem moc zvědavý, co Hrach vymyslel s tím jeho ORM nad Nette\Database a zda to bude v dohledné době použitelné na reálné projekty :-)

Doctrine je jak střílet z tanku na komára, aspoň tedy pro mě, ale čisté Nette\Database je zase jak házet šutry na tank. Navíc Nette\Database má oproti Doctrině výbornou schopnost skládat optimalizované dotazy, aniž bych musel přemýšlet, jak to zapsat (tuším že v Doctrině musí člověk přemýšlet nad DQL). Zatím mám na to vlastní ORM postavené nad Nette\Database, ale není to nic moc (základní mapování, vazby přes anotace, jednoduché entitní formuláře, to vše mi funguje, ale kdybych vypustil zdrojáky, tak se tu všichni pozvrací :-) ) a nemám čas to udělat pořádně.

Věřím, že Hrachovo řešení bude mnohem lepší než moje.

U mě rozhodně vede LeanMapper (ORM nad Dibi), které, kdyby mělo zdokumentované všechny fičury, strčí do kapsy všechna výše zmíněná řešení. Takhle je potřeba se na řešení složitých dotazů ptát Tharose. Základ zdokumentovaný je.

@Filip

Abych řekl pravdu, tak nad tímto řešením asi nejvíce přemýšlím, jen pořádně nevím jak začít…

LeanMapperu je výborné skoro-ORM, ale bohužel nemá identity mapu a má dost obskurní architekturu. Což spoustě lidem nevadí, ale pro mě je to nepoužitelné.

Začal bych tady a pokud to s Doctrine myslíš vážně, tak pokud si přečteš celou dokumentaci tak to je výborně investovaný čas.

@Filip
Určitě, když ji chci využívat, tak na pořádně ;-)

@mrtnzlml
Kouknu, dekuji

Víš, co se díky té „identity mapě“ stane na pozadí? Překvapení! Z databáze se Ti vytáhnou nejen všechny stránky, ale i všechny obsahy (všech stránek). :) To je pěkný průser…

Jo, o tom jsem se s Hrachem bavil. Je to tim, ze pri iteraci se entite priradi kolekce („Preloaded container“), do ktere aktualne patri, ale pote se ta kolekce neodstrani. Rikal, ze je to tak umyslne, ale mozna se to jeste zmeni.

Asi by jen stacilo sem (nebo jeste nekam jinam?) pridat smazani toho preloaded containeru z predchozi entity.

Honzo, je to sice hezký sport a dá se při tom zažít spousta legrace, ale já bych rád tohle klání ORMek uzavřel, protože to stojí zbytečnou energii a nikomu neprospívá (osobně nesnáším negativní marketing).

Tvé ORM se mi líbí, máš ho hezky napsané. Je tam pár věcí, které se mi tak trochu nelíbí, pár věcí je třeba dotáhnout, ale pak to bude fajnová knihovna.

Přemýšlím jen, co by mělo uživatele přesvědčit používat jej namísto Doctrine 2, která je de facto standardem pro ORM v PHP? Ten ujetý benchmark, jehož výsledek vlastně nevypovídá o ničem smysluplném, je dost slabý argument. Doctrine 2 není tak špatná, jak si pravděpodobně myslíš. Fakt Ti doporučuji více se na ní podívat. Třeba já jsem to nedávno udělal a hodně mě to posunulo, dost jsem na problematiku změnil názor.

Lean Mapper má oproti Doctrine pořád pár jasných výhod. Z podstaty svého návrhu je velmi pružný. Je to ORM, které Ti umožňuje mít zároveň přesně takové public API modelu (hlavně entit), jaké si přeješ, posílat do databáze takové dotazy, jaké si přeješ, a to vše s minimem řádků a s minimálním úsilím. To je jeho hlavní výhoda a rank, podle kterého si s Doktrínou v ničem nezadá. A věřím, že to je hlavní důvod, proč jej mnozí používají.

Jako bonus beru to, že si můžeš sám vybrat, jak moc chceš vlastně relační databázi v aplikaci abstahovat. Abstrakci lze ji mít velmi malou (výhodné třeba s PostreSQL, která toho sama umí hrozně moc) i hodně velkou. V téhle volbě IMHO strká Doctrine do kapsy.

Nesouhlasím s tím, že je to sra… Praxe ukazuje, že není.

Good luck s dalším vývojem!

Editoval Tharos (4. 6. 2014 9:12)

@hrach příště to zkus slušně pls :)

@Tharos Pozor, nikde nepíšu, že to že tam nemáš identity mapu je špatně, jenom píšu že máš prostě jinou architekturu (já tomu osobně říkám skoro-ORM). Určitě na tom jde napsat spousta kvalitních aplikací. Jediné co se snažím říct je, že mi tvoje architektura nevyhovuje a nebyl bych s ní schopný pracovat. Výrazy „správný“ a „čistý“ samozřejmě narážím na standardní pojetí ORM a DDD.

Na druhou stranu je dobře, že tu existuje alternativní architektura a né jenom další „napsal jsem lepší Doctrine“, protože napsat lepší Doctrine by byla práce na roky vývoje pro jednoho člověka a musel by být neskutečně geniální, aby to udělal lépe, než ty desítky vývojářů co na ní dělali do teď a tisíce co ji každý den testují a reportují chyby. Držím Hrachovi palce :)

Zatím mě Doctrine přijde ultra složitá.....

Bylo to naprosto nechutné chování, a proto jsem se Ti za něj taky omluvil. Víc pro to už udělat nemohu.

Ahoj, dovolím si oživit téma, abych nemusel zakládat nové, protože řeší přesně to co já.

Jak je na tom Nette/Database dnes? U některého ze starších rozhovorů s Davidem (tuším) jsem se v komentářích dočetl, že je Nette/Database zabugované a používané jen začátečníky (skrze Sandbox). Otázka je: je to pravda i dnes?

Ona mi ta „magická“ složka moc nesedí, ale zase je to pohodlné. S Dibi, které bylo prozatím můj favorit, zkušenosti taky nemám. Vrátil jsem se k PHP a webům po sedmi letech, tehdy jsem jel těžký punk s funkcema mysql_* a podobnými relikviemi, tak se pořád rozkoukávám…

Projekt nebude moc velký. Docela mě láká i LeanMapper, protože jsem v C# používal Entity a bylo to super.

Editoval Džůny (9. 4. 2015 10:14)

Trošku se divím, že jsem ještě na Nette fóru nezavadil o nějakou slušnou Active Record vrstvu, ani zmínka.
U RoR se mi s Active Recordem pracuje dobře a jednoduše, to to nemá v oblibě nikdo okolo Nette?

… a protože David je ten guru, který půlku z nás učil čistě programovat, tak asi není nikdo, kdo by splňoval najednou dvě základní podmínky – 1) být schopný napsat tuto vrstvu v rozumné kvalitě s testy a za 2) používal active record :)

@DavidGrudl: Když už se na to narazilo, kdo tedy vyvíjí NDb a NDbT? Myslel jsem, že @hrach? Případně jak vypadá budoucnost NDbT? Díky.

@Džůny: Před dvěma lety byla situace trochu jiná, to bych ti NDb(T) nedoporučil, přestože byla již součástí
Nette. Dneska, pokud nemáš nějaký konkrétní důvod použít něco jiného, bych naopak řekl použij ji. Pokud se ti nelíbí magie, tak nemusíš používat Nette database table, ale čistou Nette database (vesměs příkaz query a fetche), přestože snad ve všech ukázkách se využívá právě možností NDbT (je to dost návykové, takový napůl ORM, taky z NotORM vychází).
Jinak jeden z těch důvodů nepoužívat NDb by mohl být požadavek na složité dolování dat (tj. využívat opravdu všech, i málo známých, možností SQL). I když, i tento pocit je možná pozůstatek z doby před těmi dvěma lety…

TL;DR:
Pokud potřebuješ podmínku v LEFT JOIN ON, vlastní ALIAS tabulky, FORCE INDEX, a další potvůrky, tak NDBT nebrat.

@Džůny: Osobně opužívám NDBT – Selection a spol – na docela velkém projektu a jak píše Šaman, dokud nepotřebuješ používat kapku složitější SQL, je ok.

Horší bude situace, když uprostřed projektu zjistíš, že kapku složitější SQL potřebuješ, jako my :-)

Typický příklad: Potřebuješ vytáhnout kategorie, a k nim pokud existuje, tak jazykový překlad, pokud překlad neexistuje, stejně ty kategorie chceš vytáhnout, a vypsat aspoň bez překladu.

NDBT:

$selection = $this->db->table('category');

foreach($selection as $category) {
	$translation = $book->related('category_translation')->where('code', 'cz')->select('category_translation.caption');
}

Což se sice vykoná ve 2 dotazech, ale tak nějak si určitě říkáš, že jakmile tento kód budeš potřebovat na více místech, není to nic moc. V čistém SQL bys použil:

SELECT category.name, category_translation.caption
FROM category
LEFT JOIN category_translation ON (category.id = category_translation.category_id
    AND category_translation.code = 'cz')

Tak si vytvoříš třeba VIEW, ale pak zjistíš, že NDBT s view úplně kamarád není, protože nemá vazby do dalších tabulek, takže view zase zrušíš.

A přitom by stačilo mít v NDBT možnost zadávat podmínku v LEFT JOIN:

$selection = $this->db
		->table('category');
		->left('category_translation.code', 'cz')
		->select('category.name, category_translation.code');

Takže Ti potom nezbyde, než napsat pull request: https://github.com/…te/pull/1436 který bude zamítnutý, protože tuto vlastnost v NDBT Hrach nechce. A pak si fakt v loji, protože tuto feature potřebuješ, nechceš mít kód připočůraný samým ->related()->where()->select()

Pak zjistíš, že potřebuješ, stejně jako v SQL, aliasovat tabulky.
Toto taky NDBT neumí, a ani sem se už nepokoušel napsat pull request a prostě si NDB forknul.. https://github.com/…rts/database

@Fafin naprosto chapu tvoji frustraci (viz muj sign;)