Architektura nad Doctrine2

Nenapsal si co by bylo vystupem $currencyCalculator->calculatePrice přímo skalár vypočítané ceny? Jinak si osobně myslim, že find a ostatně entity_manager do presenteru nepatří. Veškeré persisence by měli být ve fasadě.

Mě jde hlavně o to, že každý tvrdí, že fasady by měli být znovu použitelné, tak se ptám jak. Protože když mi fasáda vrátí cokoli jiného než entitu nebo kolekci, tak znovu použitelnost je diskutabilní.

Já tomu sice úplně nerozumím, ale fasády přeci nejsou proxy objekty nebo jo? Příklad: mám formulář pro přidání nového záznamu, který chci oživit. Pro oživení můžu:

1. namatlat kód do presenteru

function formSubmitted(Form $form, $values) {
	$entity = new Entity;
	// .. přiřazení odeslaných hodnot do vlastností
	$this->entityManager->persist($entity);
	$this->entityManager->flush();
	$this->flashMessage('Entita ' . $entity->id . ' vytvořena');
}

2. vytvořit si na to třídu (fasádu – nebo to je asi jedno jak se tomu říká ne? Prostě služba, která má jasně dané API pro nějakou konkrétní akci), jejíž jediná zodpovědnost bude ze zaslaných údajů vyrobit novou entitu.

function formSubmitted(Form $form, $values) {
	// nevím, jestli "persistentEntityFactory" je dobrý název, lepší jsem nevymyslel :-P
	$entity = $this->persistentEntityFactory->create($values->name, $values->whatever);
	$this->flashMessage('Entita ' . $entity->id . ' vytvořena');
}

A z toho pak vyplývá ta znovupoužitelnost, protože té třídě je jedno, kdo ji volá. Můžu třeba využít Kdyby/Console a použít tuto třídu ve vlastním příkazu. Také mi přijde čistší si injektnout službu, jejíž jediná zodpovědnost je to, co chci, ne nějaký monster-object, který dělá vše.

BTW myslím si, že je asi docela rozumné si na tyto fasádní třídy psát i interfacy. Je to sice trochu psaní navíc, ale pak má každá fasádní třída jasně dané API, které musí splnit. Navíc, vyžadováním interfacu nezávisíš na konkrétní implementaci – občas je třeba něco někde přiohnout, ale jinde nechat výchozí chování, není problém si napsat další implementaci, zaregistrovat v configu s „autowired: false“ a ručně injektovat kam je třeba.

Pokud jde o dolování dat: +1 pro QueryObject, pomocí kterého se dá krásně zapouzdřit dolovací logika do čitelného API. Ale stejně bych si na něj vždycky udělal aspoň továrnu a tu vyžadoval, než mastit „new“ do presenteru ;-) (hint: automaticky generované továrny fungují na všechno, nejen na komponenty)

Znovu opakuji, že tomu sám moc nerozumím, hlavně pokud jde o pojmy – ale i se samotnou Doctrinou dělám spíš krátce. K této architektuře jsem dospěl tak nějak „evolučně“ a zatím mi to dává takto smysl, ale je samozřejmě možné, že budu někdy za měsíc opět přepisovat komplet celý model :-P

@jasin755

Entity
U entit, asi není co řešit. Gettery/settery bez logiky.

To je veliká škoda, tímto se připravuješ o řadu skvělých možností, které Ti právě použití ORM přináší.

Ještě mě napadá 1 připad kdy si nevím moc rady a to je když se používá Paginator. V tomto případě nevím co si mám z Repository vrátít, protože když si zavolám getResult(), tak příjdu např. o počet celkových vysledku, který potřebuji.

Nepouživám Kdyby\Doctrine. Mám pouze čisnou Doctrine2

@jasin755:

Mám na mysli třídy, které dědí Kdyby\Doctrine\QueryObject.

Použití Kdyby\Doctrine mohu jen a jen doporučit, tím že ji nepoužíváš si dle mého názoru jen zbytečně komplikuješ život. ;-)

Jinak by tě mohl zajímat tenhle dnešní twít od @FilipProcházka.

Editoval enumag (5. 12. 2014 12:58)

Mile rád nějakou takovou entitu ukážu (a moc rád se o ní i pobavím). Budu mít prostor věnovat se tomu dneska večer.

@mkoubik: Přesně tak, hezká ukázka.

Mám v hlavě několik dalších ukázek, i komplexnějších, ale sepíšu je až večer. Chci ty ukázky očesat na nezbytné minimum, aby byly názorné.

@jasin755 nenahrazuje, rozšiřuje. Viz dokumentace

DAO ani používat nemusíš, můžeš si nakonfigurovat, že chceš používat jen vylepšené repository

doctrine:
	defaultRepositoryClassName: Kdyby\Doctrine\EntityRepository

Ty věci co přidává EntityDAO už zase tak zásadní nejsou, v podstatě to samé dělá EntityManager (a často i lépe). Ovšem ta vylepšení co přidává „můj“ EntityRepository jsou super :)

Já to zpochybnil už dávno :) (tenhle commit bylo moje definitivní rozhodnutí, že dao není ideální, pochybnosti jsem měl už dlouho předtím).

Dao::save() vypadal jako super nápad, než se v praxi ukázalo že to není super nápad a v ten moment EntityDAO trochu ztratil smysl. Stále ho používám na prototypování, ale vždycky použití nakonec přepíšu tak, aby využívalo jenom metody z EntityRepository a na všechny ty save operace využívám EntityManager.

Mazat ho rozhodně v dohledné době neplánuju, na zpětné kompatibilitě si zakládám :)

@jasin755 o QueryObjektech mám v docce celý článek, přečti si ho :)

Díval jsem se ještě na Kdyby/DoctrineCache ke které dokumentaci nemáš dá se říct žádnout. Zajímalo by mě vlastně co to je, protože implementaci resultCache jsem již řešil a moc dobře jsem nevyřešil. Resp problém byl s jeji invalidaci. Chtěl jsem ji rozsáhle používat po celém projektu a cachovat do Memcache, ale nakonec se mi to podařilo jenom u routeru, kde se celkem dobře cachuji i invaliduji objekty, které používám.

Co by si povedal na nahradenie setFinished() za finish()?

Dobrý dotaz. :) Záměrně ji mám pojmenovanou setFinished, a to proto, protože klasické finish ve mně evokuje, že zavoláním takové metody se provedou všechny úkony, které je zapotřebí při dokončení objednávky provést. Takových úkonů je hodně: nasypání messages do front (aby se odeslaly e-maily), odebrání vazby na objednávku z uživatelovo košíku (práce se session), flush modelu… a to řešit v entitě by už bylo nevhodné. Stručně řečeno proto, protože to je práce s vrstvami, o kterých je zbytečné, aby entita vůbec věděla (sessions, messages, flush).

Proto tomu říkám setFinished (upozorňuji, že ta metoda nepřijímá žádný parametr, v praxi je to vážně jenom $order->setFinished()), čímž se čtenářovi kódu snažím říct, že to volání nějakým způsobem nastaví stav modelu, ale neprovede všechny potřebné úkony.

Přemýšlím, jestli se mnou nastíněné myšlenkové pochody dají nějak zobecnit a napadá mě zhruba následující…

• Jedná se o validaci dat?

  Rozhodně to udělám v entitě, protože ty přímo obsahují data, která k té validaci potřebuji. Plus chci, aby byla zvnějšku „vrstva entit“ nerozbitná.

• Jedná se o dopočet nějakých skalárních hodnot v entitě/entitách?

  Rozhodně to udělám v entitě, protože přímo obsahují data, která k tomu potřebuji.

• Jedná se o vytvoření/odstranění/úpravu entit, na které má nějaká „hlavní“ vazbu?

  Rozhodně to udělám v entitách, protože opět vše, co k tomu potřebuji, mám právě v entitách.

• Jedná se o nějakou práci se session, messages, view a tak podobně?

  Nebudu to dělat v entitách, protože je kontraproduktivní, aby entity o těchto částech aplikace vůbec věděly.

Není to vyčerpávající souhrn, ale věřím, že je z toho patrný jistý přístup. Bonusem pak je, že v praxi zjistíte, že spoustu public getterů a setterů vůbec nepotřebujete a můžete zahodit. :) Právě proto, protože danou logiku neřešíte mimo entity, nýbrž v entitách.

Editoval Tharos (6. 12. 2014 14:21)

Čeho chceš prosím dosáhnout? Mě z toho zápisu přijde, že chceš ohýbat traverzu :-).

Vždyť entita ani nemá vědět že nějaká url existuje, co když budeš mít proces v command lajně?

Jan Endel napsal(a):

Vždyť entita ani nemá vědět že nějaká url existuje, co když budeš mít proces v command lajně?

Ano i né. Za ideální situace by entita neměla vědět o ničem, ale tohle elegantněji řešit podle mě nejde. Entitě nastavím jenom anotaci @URL ve které je jenom jméno nic vic. Samotná entita s tím ani nepracuje. Jenom nese tuto informaci. O zbytek se starají fasady routeru, které hledají tyto entity a z DB si už načítaji vazby, které mezi sebou mají. Následně se rekurzivne magicky skládá QueryBuilder podle vazeb.

Je to z důvodu, že řešení je multisite a každá site může mít jinou strukturu adres a struktury jsou např.:

example.com/category
example.com/subcategory
example.com/product
example.com/subcategory/8
example.com/subcategory/100/8
example.com/product/8
example.com/product/8/100

Tzn. se do URL ukladá cesta odkud se uživatel proklikal do daného produktu či kategorie s tím, že se kontroluji vazby mezi sebou (zda ten produkt v kategorii opravdu je, zda ta subkategorie je ve všech vyjmenovanych nadřazených kategoriích + pořadí atd..). Takže držet tuto malou informaci u Entity mě nepřipadne nijak špatné.

@FilipProcházka
Za nové téma se asi omlouvám, ale kdbych to měl brát do důsledku tak by se tohle vlákno mělo rozseknout min na 3 další. Takže mě snad omluvíš.
Jinak jsem si následně všiml, že tvoje BaseEntity je opravdu Mapped SupperClass. Na to správně používání bych se rád zeptal.

To by teoreticky asi šlo, zkusím nad tím zauvažovat. Jinak začal jsem s implementaci Kdyby\Doctrine a narazil jsem na nejasnost. Když si vytvořím QueryObject tak jak z něj dostanu ResultSet aniž bych použil DAO?

Hm, architektura nad doctrine…já mám rozsekaný model podle domén na jednotlivé namespacy (model\payments, model\carPooling, apod.) a uvnitř toho mám vždycky třídu, která si drží Dao a entityManager a má metody, které potřebuji na crud operace. A potom mám třídu, která má k této přístup a obsahuje aplikační logiku. Entity mám jenom na validaci dat, zapouzdření a nějaké jednoduché operace nad jejich properties.

Ale zajímala by mne jedna věc: jak elegantně dělat modulární aplikaci nad doctrine? abych měl například entitu user, extension na platby, extension na správu souborů…jak té jsou best practise, aby entita user měla jako properties peněženku (v případě plateb) soubory, které vlastní (v případě správy souborů) a nemusel tu entitu moc upravovat, tedy aby šly tyto extensions snadno přidávat/odebírat bez velkého zásahu do entit, ale přitom aby byly entity provázané (user měl referenci na svou peněženku apod.)?

@jasin755 metody select a createQueryBuilder pracuji s konkretnim typem entity

Azathoth napsal(a):
Ale zajímala by mne jedna věc: jak elegantně dělat modulární aplikaci nad doctrine? abych měl například entitu user, extension na platby, extension na správu souborů…jak té jsou best practise, aby entita user měla jako properties peněženku (v případě plateb) soubory, které vlastní (v případě správy souborů) a nemusel tu entitu moc upravovat, tedy aby šly tyto extensions snadno přidávat/odebírat bez velkého zásahu do entit, ale přitom aby byly entity provázané (user měl referenci na svou peněženku apod.)?

Tak tohle by me taky zajimalo. Mam modlarni aplikaci sice, ale ty Entity porad nemam nijak rozumne vyresene a musim to pravovat, takze uplne modularita vyndam tohle a strcim tohle nefunguje. Hledal jsem jednim casem a nenasel. Napadli mě jedině nějaký Doctriní listenery, které by kontrolovali, že když bude tahle extensiona povolena, tak se přidají properties. Ale s tím se mi nechtělo dělat, protože by to bylo asi dost složité…

@jasin755

Chvilku jsem si s tím hrál a funguje mi to i když to nemá moc hlavu a patu.

Mám QueryObject Product, který obsahuje různé metody na dolování dat k produktu. ResultSet jsem z toho získal pomoci … ale zároveň funguje … a dokonce i:

To je jednoduché, createQueryBuilder() nad Queriable vždy vytvoří „základní“ query builder nad danou entitou ke které patří.

Pokud bys udělal

protected function doCreateQuery($queriable)
{
	$qb = $queriable->createQueryBuilder()
		->select('e')->from(Entity\Product::class);

	// ...

	return $qb;
}

tak už to bude pracovat vždy jenom nad Entity\Product.

Nevidím moc důvod to svazovat pro konkrétní entitu, na druhou stranu když se liší „root“ entita toho DQL (ta co je ve from) od entity toho DAO, tak by to možná mohlo nějakou výjimku hodit, což?

Je to trošku WTF. Proč neudělat rovnou:

$query_object->fetch()

(Popravdě jsem se i o to pokoušel tím, že tomu přehodím $this, ale pak jsem zjistil, že to implementuje jiný interface :X)

Protože něco takového by byla neskutečná prasárna,

$query = new MyCustomQuery();
$resultSet = $query->fetch();

Odkud se tam vezme connection do db a entity manager? Ze vzduchu?

Nebo aspoň:

$this->entity_manager->fetch($query_object);

To by tereticky nebyl problém dodělat, ale muselo by se striktně vyžadovat, že výsledné DQL musí definovat uvnitř z jaké entity selectuje. Nevidím v tom ale nijak zásadní rozdíl.

@FilipProcházka takže navrhuješ, aby tyhle extensions byly závislé na userovi a ten o nich vůbec nevěděl? To zní hodně dobře.
Ale kdybych chtěl připojit odkaz na nějaký objekt do více entit, tak by to chtělo jednostrannou vazbu na straně těch entit…nevíš, jak by se dalo elegantně udělat tohle?

@jasin755 Řekl bych že ten řádek ->from(...) je zbytečný a ten alias 'ps' bys měl předat rovnou metodě createQueryBuilder. Pak to se špatným repository fungovat nebude.

Editoval enumag (10. 12. 2014 14:09)