V čem je dotrina tak úžasná oproti NDB nebo dibi aj?

zool

Ahoj pořád tady čtu o doctrine a nějak jsem zatím nepochopil, v čem je její výhoda? Zjistil jsem že dokáže generovat upravovat atd databázi, budiž, když však mám soft který to dělá taky a navíc to vidím krásně přehledně v tabulce, tak proč používát toto?
Dále bych se chtěl zeptat, když tahám data z DB, a to takto, vazba M:N
a mám

foreach($article->categories as $categorie)
{
	echo $categorie->name;
}

Výpíše všechny jména kategorii, kde je článek uložen, ale jak to omezím jen na kategorie, které jsou ve stavu povolené. Chybí mi tam where.
Když použiji DQL tak to chápu, ale proč používat tento kod, když můžu použít klasické SQL. A mám to taky hned napsané.

Díky

Jan Endel

Hlavní rozdíl je že z dibi vypadávají pole/arrayHash a z doctrine vypadávají tvoje entity jako třeba article – takže v tvém případě můžeš rovnou napsat něco takovéhoto:

foreach($article->categories as $categorie)
{
	if ($article->isVisible()) {
		echo $categorie->name;
	}
}

a programátorsky se to krásně čte, než nějakým způsobem parsovat pole.

Kdyžtak bych tě ještě odkázal tady

F.Vesely

A kdybys nechtel tahat vsechny kategorie z database, ale pouze ty viditelne, tak muzes pouzit Criteria. Vypadalo by to nejak takto:

/**
 * @ORM\Entity
 */
class Article {
  // ...
  public function getVisibleCategories() {
    $criteria = Criteria::create()->where(Criteria::expr()->eq("visible", true));

    return $this->categories->matching($criteria);
  }
}

foreach($article->visibleCategories as $categorie)
{
	echo $categorie->name;
}

zool

Jan Endel

To si jako vyberu vsechny záznamy z DB a pak budu kontrolovat radek po radku, to si myslím, že není moc praktické.

F.Vesely

No vždyť přece používáme Framework a knihovny proto, aby jsme psali méně kodu, tak proč to psat tak složitě, když třeba v NDB to napíši na jeden řadek? Jo a myslím, že je to taky programatorsky přístupné.

Ještě jsem se chtěl zeptat, existuje v dotrine už nějaký nástroj, který nahraje seznam sql dotazu pres dumpsql? Když jsem se tak zběžně díval, tak jsem neenašel.

David Matějka

Vyhody doctrine nepoznas po precteni jeji dokumentace, naopak – bude pripadat slozitejsi nez NDBT. Musis psat entity, musis delat tohle a tohle… zatimco v ndbt napises jen ->table('article') a je to. U vetsiho projektu ale s ndbt narazis – jak s omezenim NDBT samotne, tak s limitaci toho patternu obecne. Z ndbt dostanes jen nejaky ActiveRow, coz je jen obalka nad daty – nemuzes tam snadno pridat nejakou logiku.

Pouze jednoduchy priklad – mas produkt a ten ma sloupecek cena bez dph a hodnota dph. V sablone chces vypsat cenu s dph, jak to udelas s ndbt? Provedes vypocet v sablone? Napises si filtr? V doctrine si proste napisu do entity jednoduchou metodu. A nedej boze aby ta hodnota DPH byla pres nejakou relaci, to uz by si s ndbt musel delat v sablone poradny prasarny. (Navic se s logikou v entitach muzes vyhnout duplikovani kodu.) A nebo bys proste zjistil, ze bez entit to nejde a udelal by sis je rucne, viz treba addons portal. Doctrine vi, ze pristup, ktery pouziva ndbt, je pro vetsi projekty neudrzitelny a umoznuje ti snadneji vytvorit objektovy model.

A priklad s dph byl pouze primitivni, v entitach toho muzes delat vic, jak ukazuje @Tharos. Do entit si muzes pripsat validacni pravidla, aby se entita nedostala do nekonzistentniho stavu atd. atd…

tak proč to psat tak složitě, když třeba v NDB to napíši na jeden řadek?

zapisovat ->where() do sablony neni idealni (a tady zas narazime na limitaci NDBT, „spravne“ to s NDBT snadno neudelas), diky te metode v doctrine entite to sablonu odstini od znalosti databaze, proste chces, at ti to vrati viditelny kategorie a ta metoda se o to postara. A zas s tvym pristupem by ses nevyhnul duplikovani kodu, kdybys chtel viditelne kategorie napsat na vice mistech

A jeste jedna vec, ktera ti ulehci praci ihned. V ndbt mas vsechno „ActiveRow“, takze typehinty projde radek z kterekoliv tabulky, navic z public api tridy ActiveRow nevidis, co ma ta tabulka za sloupecky. To, ze s doctrine muzes vsude pouzivat jako typehinty primo ty entity tak nehrozi, ze ti nekdo nekam posle radek z jine tabulky nez cekas. A navic ti IDE krasne napovida vsechny metody, ktere entita ma.

F.Vesely

A pridej k tomu jeste uplne cool eventy a jsi na uplne jinem levelu. :)

zool

David Matějka

Přesně tak to vidím po prostudování dokumentace. Ono i v NDB mám vytvořené modely, a z tech tahám jen potřebná data a předávám je do šablony a šablonu mám pak čistou. Ale je pravda, že tak uhledně to nevypadá.
Už jsem se pro dotrinu rozhodl, ale potřeboval jsem namotivovat, za to díky.

Editoval zool (9. 5. 2015 17:41)

Azathoth

Já mám Doctrine hodně rád, protože mám všechno v objektech, ty mají metody a ty mi IDE našeptává. Vytáhnu z databáze objekt, který má pevně dané metody a v anotaci té metody, co to tahá z databáze řeknu, jaký je to objekt. A potom dále pracuji s tím objektem, gettery tahám hodnoty, settery nastavuji hodnoty, IDE (phpstorm) mi provádí statickou kontrolu kódu a nemusím se bát, že někde udělám překlep. U pole si musíš pamatovat všechny klíče, názvy tabulek…tady mi to našeptává gettery a settery, které mi podle fieldů vygenerovalo IDE. A nemusím si to sám přesypávat z activerow do objektu, protože od toho je tu doctrine. A taky, když chci vytáhnout objekty přes nějakou relaci, tak nebusím psát joiny, prostě zavolám getter.
A místo insertu řádku si přehledně persistuji objekt, kter má svůj konstruktor, v konstruktru se mi nastaví defaultní data, přidají potřebné další objekty, které se kaskádně persistují…
A také například používám na dateTime https://github.com/…sbitt/Carbon knihovnu.
A v doctrine jsem malou úpravou zajistil, že všechny datetime, které chci, dostanu z databáze jako instanci Carbonu. Což mi NTDB nebo Dibi nedá. Stejně tak u Money objektů, když pracuji s financemi.