Jak implementujete servisní třídy vy? Předávání dat, business logika

Děkuji za odpověď, alespoň někdo se ozval :) Jenom tedy to přímo neřeší mou problematiku, tj. jakým způsobem předávat data, zároveň tedy určitě bych to nedával do jedné třídy – nemám rád nějaké god objekty, které dělají tolik věcí, čili bych určitě zůstal u rozdělení funkčnosti.

Mě hlavně šlo právě o tu obecnou logiku, příklady se zaplacením objednávky, vytvářením produktu byly jen příklady, čili ty změny stavu objednávky přes flagy, to už jsou konkrétní implementace.

Díky za odpověď, v podstatě tímto principem to nyní dělám, jen tedy akce, které přímo nesouvisí s procesem tj. právě například to odesílání emailů při označování objednávky za zaplacenou navěšuji přes listenery (Kdyby\Events).

Spíše tedy jsem přemýšlel, jestli neexistuje nějaké know-how, které mi chybí – nejsem moc spokojen právě s tím principem například vytváření produktu.

Tím, že využívám doctrine, tak z pohledu OOP se na to hodí továrnička, která slouží k vytváření instancí, takže bych si mohl udělat nějakou továrnu, ale jakmile mám další zdroj, třeba vytváření produktu přes API, tak už mám jiný formát dat, tudíž bych potřeboval další továrničku, OK. A najednou přibude vytváření produktu z importu, které navíc ještě vytváří například kategorie, či značku apod. ...... a tady už by se duplikovala logika, jelikož to vytváření právě nebývá jen na setování properties na objekt, ale i validace.

Takže právě jen hledám jestli mi nechybí nějaký kousek v těch mých skládačkách – entity, získávání dat přes doménové objekty, atd. to vše mám snad relativně hezky pořešené, ale tohle je taková jedna část designu aplikace, ve které si myslím, že mi něco chybí.

Jo když nadtím přemýšlím, tohle by asi šlo :) Já právě hledal jestli někdo nemá nějaké „super magic“ řešení, u které bych si řekl – jasně tohle je bomba, to mi ulehčí práci, ale ve finále takové asi neexistuje, přeci jen je to dost obecný problém.

Původně jsem si hrál s myšlenkou, kdy mám různé readery (FormReader, CsvReader, RpcReader, …), který předám nějaký mapper podle vstupu a ty mi namapujou data na nějakou Collection (v podstatě ArrayHash) a to by se vždy předávalo nějakému procesu – vytvoření objednávky, zaplacení objednávky.. zároveň by každý proces věděl, jaká data přesně potřebuje.

Potom ale co jsem si to celé napsal (i s unit testama :D) (… https://github.com/…ocessManager) tak jsem zjistil, že mi to tahle myšlenka spíše komplikuje než-li usnadňuje …

dcepelik no zeptat se samozřejmě můžeš, ale jak jsem již psal v úvodu, tak jsem to plácnul jako příklady, jinak mi vůbec nejde o žádné označování objednávek či vytváření produktů atd. Jde mi o obecnou logiku servisních tříd a rozvržení těchto procesů.

Ale tedy, pokud to měl být sarkasmus, jelikož si myslíš že označit objednávku za zaplacenou nic moc složitého není, tak naopak zrovna tohle může obnášet mnoho – co jsem dělal asi před půl rokem, tak proces zaplacené objednávky dělal následující:

• označení sloupce za zaplaceno (= to co asi čekáš)
• odeslání emailu, že bylo zaplaceno
• u našeho zboží: kontrola a rezervace položek na skladě
• u zboží ext. dodavatelů: objednání položek u dodavatelů
• odeslání platby do účetního systému
• vytvoření výdejky pro sklad

:)

Můžeš mít různé vstupy

• CreateOrderForm + CreateOrderFormMapper
• CreateOrderApiCall + CreateOrderApiCallMapper

ze kterých ti vyleze entita objednávky a tu pak předáš kam potřebuješ. Podle toho jak by ten mapper byl velký je můžeš schovat do facade, popřípadě na ně udělat samostatnou třídu.

Nebo ti klidně ten mapper může zastupovat celou tu facade a rovnou delegovat na služby. Pokud v něm je pouze ta logika, která se týká konkrétního formuláře/api-callu a všechno ostatní se deleguje tak na tom nevidím nic špatného :)

Jiří Nápravník no já jsem to řešil takto:

• Služba PayOrderProcess by měla metodu markOrderAsPay(Order $order), která by pouze označila objednávku za zaplacenou a flushla do databáze, zároveň by měla událost onPay(Order $order)
• Listener PaidOrderNotification navěšený na událost onPay, posílá email
• Služba CreateWarehouseReservation s metodou reservation(Product $product, $amount), která rezervuje položku zboží ve skladu
• Listener WarehouseReservation navěšený na událost onPay, projde objednávku a pro každý produkt volá metodu reservation v té službě

...... ostatní procesy co jsem uvedl totožně jako s tím skladem .. listener + services

Fasády jsem v podstatě doposud nepoužíval, do presenteru případně importu atd. si vždy předávám ty procesy, ale jinak by šla udělat fasáda nějaký OrderManagement, která by měla tu metodu markOrderAsPay() a zároveň třeba ještě cancelOrder() atd. což pokud je více akcí, tak aby se nemuseli předávat všechny procesy do presenteru zvlášt, případně pokud bych chtěl nahradit PayOrderProcess jiným objektem, tak by to bylo jednodušší..

@frosty22 co se týče validace, tak bych to v klidu nechal na entitě nebo na datovém typu (v Doctrine2 se dá přeci vlastní datový prvek vytvořit). No a vstupy by mohla validovat facada nebo formulář. V service bych už nic nevalidoval maximálně občas vyhodil nějakou tu výjimku v důsledky jiné výjimky a nechal to probublat až k facadě nebo presenteru.

Děkuji vše za návrhy, zatím jsem z toho bohužel stále smutný :) Zkouším teď různé přístupy, ale ta architektura se mi stále nezdá tak cool. Ale myslím, si že je to stále pole nezoranné, a co jsem viděl mnoho projektů od různých programátorů, tak každý to řeší úplně jinak a někdy i třeba vůbec – vše v presenterech, takže třeba to i někomu dalšímu pomůže.

Zkusím pro příklad, jak to mám nyní, na triviální CRUD operaci:

Zadání: Kontakt má neomezeno kontaktních údajů (jednoduché 2 entity)

Entity:

• Contact – v podstatě jen settery, gettery
• Item – položka kontaktu, má typ a hodnotu (třeba telefon, email, atd.)

Formuláře (továrničky):

• ContactFormFactory – vytváří form pro kontakt + s možností přiřazení položek kontaktu
• ItemFormFactory – vytváří form pro přidání jedné položky kontaktu

Továrnička na entity:

• ContactFactory – metoda create přijímá parametry, které validuje a vytváří a vrací instanci entity Contact
• ItemFactory – stejné jako contact + hledá duplicitu, a vrací entitu Item

Fasáda:

• ContactFacade – má v tuto chvíli metody:

--- addItem(…) která volá ItemFormFactory, vytváří Item tu předává kontaktu u volá na DAO objektu pro Contact metodu save()

--- createContactFromForm(…) jelikož formulář z ContactFormFactory, již je složitější – vytváží spolu s Contact i několik Item, tak jsem toto delegoval do nové třídy CreateContactProcess, která tedy prochází ten formulář, následně volá jak ItemFormFactory, pro vytváření jednotlivých Item, tak i Contact

=========
Presenter tedy posílá zprávy na ContactFasade, která komunikuje s továrničkama entit, a s DAO objektem pro ukládání.

Ale už nyní je tu jeden problém, co když chci updatovat kontakt, na to použít ItemFormFactory nemůžu protože to mi vrátí novou instanci, takže to nasetování na entitu, a validaci entity musím provádět znovu na jiném místě. Nebo by se factory, nechovalo jako továrnička, ale nějaká služba, která by v případě, že entita existuje jí nastavila nové parametry a vrátila ji, ale v tomhle případě bych musel při vytváření kontrolovat duplicitu jinde a nevyhazovat vyjímku.

No koukám jsem se sakra rozepsal, a pochybuji, že se to někomu bude chtít číst =)
Ale je to zatím prostě magie :) optimální cesta nenalezena.

Editoval frosty22 (19. 11. 2013 12:52)

@frosty22 nejsou továrničky pro Entity tak nějak zbytečné?

co když chci updatovat kontakt, na to použít ItemFormFactory nemůžu protože to mi vrátí novou instanci, takže to nasetování na entitu, a validaci entity musím provádět znovu na jiném místě

Co vložit do té metody Entitu a nestarat se o to kde se vzala? Pak ji prostě uložit a Doctrine2 se už postará o to jestli ji mí insertnout nebo updatnout. Entitu bych asi vyvolal na úrovni presenteru a předal do Facade.

Status Entity se dá zjistit pomocí \Doctrine\ORM\UnitOfWork::getEntityState($entity) a vrací:

STATE_MANAGED 1
STATE_NEW 2
STATE_DETACHED 3
STATE_REMOVED

A pak si podle statusu můžeš i sám řídit co s tou entitou uděláš …

arron tak já se nesnažím na poprvé – v podstatě různé způbosby architektury se snažím už pře rok resp. snažím se u navrhovaných projektů nalézt ten svatý grál, kde si řeknu tohle je ono, přesně tohle mi chybělo. Ale u každé architektury narazím pak na něco, co se mi implementačně nelíbí a již to většinou nejde dobře řešit, tak mě napadlo zkusit se zeptat, jak to řeší ostatní, zda mi nějaká část nechybí, něco mě nenapadlo.

Ale así máš pravdu, že prostě ideální stav neexistuje a chce to stále refaktorovat dle nových požadavků.

jablon nemyslím si že továrničky jsou zbytečné, ale spíše tedy ASI by to nemusela být továrna, ale spíše rozšířit asi funkčnost na mapper, aby dokázala i přijmout instaci na settovat. Ikdyž zase na druhou stranu leč se editace a vytváření může zdát dosti podobné, tak ve finále je to podobné jen v nasettování proměnných a validaci, ale nasettování bych neviděl problém v duplikaci, to není v podstatě funkční kód, a validace zdelegovat jinam. Ale nevím se stavem entity by se taky asi dalo něco vymyslet, jak píšeš.

Máš pravdu vymýšlet univerzální řešení není optimální a pravděpodobně ani neexistuje :)

Trochu se v mísím. Řeším neco podobného a zatím bohužel duplikací kódu.
Mám entitu kde uchovává emailové adresy. Každý user jich může mít vícero. Když někdo přidá novou adresu tak se ji založí entita a zároveň se pošle validační email pro ověření adresy. Tento validační email se pošle i na vyžádání usera.

Adresy přidávám jak v komponentě, kde je form pro přidání nové adresy tak i v presenteru editace účtu kde user zvolí primární mail a pokud je to nová adresa tak se pošle ověření a taky v procesu založení účtu. Takže aktuálně mám poslání validačního emailu na 4ech místech.

Jaký by tedy byl správný postup? Využít k tomu nějak Kdyby\Events? Udělat si nějakou service co bude řešit ono posílání emailu? Měla by řešit jen ono poslání nebo i třeba samotné uložení? (asi jen to poslání co?;))

@webdata: tak mimo mísu tolik nejsi, ale to co jsi popsal, to je mi víceméně jasné – tady řeším problematiku té části, kterou ty uvádíš jako „model“. V podstatě, to co jsi popsal vypadá, že máš nějakou GOD třídu, která zařizuje všechno v rámci dané „entity“ případně jejich vazeb, a ta ti s novými fukcemi roste, což určitě nechci dělat. (možná se mýlím, ale podle toho co uvádíš, jsem to tak odvodil).