ORM: LeanMapper vs Doctrine

@hrach už nextras/ORM vyběhlo z fáze beta?

@Tharos Rád bych se Tě, jako vývojáře LeanMapper, zeptal, jaké máš s LM plány do budoucna, budeš ho i nadále podporovat? plánuješ nové funkce (chybí Ti tam vůbec něco)?

Pokud se ti líbí OOP, máš rád abstrakci, tak je Doctrina dobrá volba. Je to sice „moloch“, má svoje nevýhody (resp. má nevýhody jako všechny ORM, tj. že nedocílíš maximálního výkonu jako s pure-SQL, či je náročné používat db-vendor-specific funkce/fičury, je to ukecané, …), nicméně za všechno negativní ti dá mnohem víc pozitivního, teď jen otázka, zda to dokážeš ocenit, resp. využít.

Pokud ti vadí ukecaný kód, chceš maximální výkon, chceš mít přístup ke všemu co ti tvoje databáze nabízí, pak jednoduše nechceš ORM. Můžeš udělat kompromis, vzít „trochu“ ORM, zahodit pár vrstev abstrakce, osekat to, přidat trochu magie, tím se výkon o něco zlepší, ukecanost nejspíše také a ve finále ti vznikne něco jako LeanMapper.

Nedá se říct, co je lepší. Protože je to hlavně o filozofii a o tom, co ti líp padne, jaký přístup je ti sympatičtější. V určitých pohledech bude mít každý z frameworků nevýhody, jinde zase výhody, ale v každym případě seš schopný ten CRUD napsat a docílit velmi podobného výkonu a z pohledu uživatele aplikace to bude úplně stejné.

Editoval Tomáš Kolinger (4. 2. 2015 11:28)

@Tharos Díky za vyčerpávající odpověď. Čekala jsem něco v tom smyslu, ale nebyla jsem si jistá podrobnostmi.
@hrach Díky, zkusím, je fakt, že vlastní praktická zkušenost je nenahraditelná.

Napadlo mě snížit ukecanost Doctrine přidáním nějaké magie (fakt se mi nechce psát getter na každou property, je to nezáživné a dost náchylné na chyby z nepozornosti), ale nejsem si jistá, jestli je to úplně dobrý nápad.

Má ta ukecanost Doctrine nějaký konkrétní přínos? Je to faktor, který mi vadí asi nejvíc, vstupní bariéra je jednorázový náklad, ale ta ukecanost mě bude stát čas pořád.

@chikeet tp je právě to krásné na ORM – entity nemusí být jen obálky nad daty, pro příklad jak vypadá kousek naší order:

class Order extends BaseEntity
{
	/**
     * anotace ...
     */
	private $payedBy;

	/**
     * one to many vazba
     */
	private $notes;

	public function isPayedByCash()
	{
		return $this->payedBy === self::PAY_CASH;
	}

	public function getPreparationNote()
	{
		$criteria = Criteria::create();
		$criteria->andWhere($criteria->expr()->eq('type', OrderNote::TYPE_PREPARATION));

		return $this->notes->matching($criteria)->first();
	}
}

a tímhle způsobem se nám dost logiky schová právě do entit s krásným api – a to je jedna z hlavních sil doctrine :-).

Editoval Jan Endel (4. 2. 2015 18:11)

chikeet napsal(a):

Napadlo mě snížit ukecanost Doctrine přidáním nějaké magie (fakt se mi nechce psát getter na každou property, je to nezáživné a dost náchylné na chyby z nepozornosti), ale nejsem si jistá, jestli je to úplně dobrý nápad.

Má ta ukecanost Doctrine nějaký konkrétní přínos? Je to faktor, který mi vadí asi nejvíc, vstupní bariéra je jednorázový náklad, ale ta ukecanost mě bude stát čas pořád.

Doctrine je upovídaná tak trochu z principu věci. Představ si, že píšeš model nějaké aplikace úplně bez persistence, tj. bez napojení na databázi. Vzniknou Ti objekty, které budou reprezentovat nějaké smysluplné celky, a data, která budou zapouzdřovat, do nich nějak budeš muset dostat. Takže přes konstruktor či různé settery. Pravděpodobně také alespoň vybraná data z těch objektů budeš chtít nějak číst zvenčí. Takže Ti vzniknou různé gettery. Plus samozřejmě budeš chtít ty objekty mít zvenčí nerozbitné, takže budeš ta vstupní data validovat atp. No a tohle celé nijak neošidíš, to je prostě OOP. :)

A k těm objektům, co Ti vzniknou, pak ještě přidej ORM anotace.

Souhlasím, že dost věcí je rutinních, a proto není od věci si pozvat na pomoc dobré IDE (ať už pro vygenerování skeletu potřebných getterů/setterů nebo chytré našeptávání) či magické věci z Kdyby\Doctrine.

S přibývajícími zkušenostmi poznáš, že to v praxi často není tak hrozné, jak se zdá. Například zjistíš, že řadu getterů/setterů vůbec nepotřebuješ. :) Tady bych určitě chtěl varovat před přístupem, kdy si po nadefinování položek v entitě hned vygeneruješ/napíšeš gettery/settery na ně bez rozmyslu, zda vůbec budou zapotřebí. Mám podezření, že tahle praktika pak obzvláště svádí k přesunu logiky z entit do různých servisních tříd, což prostě není best practice (používáš-li plnokrevné ORM).

Editoval Tharos (4. 2. 2015 18:08)