Zpracování formuláře pomocí Doctrine

Landsman

Zdravím,

trochu jsem googlil, ale nenašel sem nějaké best pracice postupy, jak zpracovávat data odeslaná formulářem. Jeden topic zde mě navedl na myšlenku vše odehrát v modelu, pro budoucí možnost rest api, což se mi zalíbilo.

Jednoduché entity jsou v pohodě, ale laboruji s JOIN tabulkami, spojovacími tabulkami a tak dále, kde už to začíná být komplikovanější. Především dumám nad update, delete těchto vazeb.

Doporučíte mi prosím nějaké zdroje, z kterých bych si mohl tuhle problematiku nastudovat?

Díky.

Editoval Landsman (14. 9. 2016 15:54)

Tharos

No, ukázky se hledají trochu obtížně, protože řada dohledatelných postupů je diskutabilních, zda je to vážně best practice…

Mně se nejvíce osvědčil zhruba následující koncept:

Obsluha formuláře typicky jenom vezme data z něj, maximálně je trochu učeše, a pak je hned předává další službě, typicky nějaké fasádě. Tím lze hodně ulevit MVP části aplikace a presentery/komponenty nemají tendenci bobtnat. Taky se na takové fasády snadno napojují další endpointy (typicky API) a taky je vše pak lépe testovatelné.
Na změny stavu aplikace většinou používám OOP, a proto v té fasádě (or whatever) typicky následuje inicializace modelu v nějakém výchozím stavu.
Tomu modelu pak pošlu zprávu (respektive zprávy) s parametry sesbíranými v tom formuláři a model na to nějak zareaguje, tzn. nějak se změní jeho vnitřní stav.
Výsledný stav zapersistuji do úložiště, což je v případě Doctrine ORM snadné, stačí jen správně použít flush.
No a to je vše, pak už zbývá jen vyřešit, jakou vrátit response (typicky nějaký redirect).

Tak snad jsem ti aspoň trochu pomohl… :)

Editoval Tharos (15. 9. 2016 9:36)

Landsman

@Tharos Tvoje obecná rovina se mi líbí, díky. Víc by však řekly nějaké ukázky reálného řešení.

Hlavně ohledně těch navázaných tabulek, kde mám v cyklu třeba container s inputy a potřebuji doctrine říct, že chci buď přidat, updatovat současné nebo smazat. Dokáži si představit, že na tohle v doctrine bude nějaké pěkné řešení, co se obejde bez nějakého porovnávání hodnot atd, jako je to u ní pravidlem.

Editoval Landsman (14. 9. 2016 16:51)

Tharos

Pokud zůstaneme u OOP, pro lepší pochopení toho mého přístupu si klidně celou Doktrínu můžeš odmyslet. Doktrína ti umožňuje namapovat nějaký objektový model na relační databázi a přináší k tomu ještě pár vychytávek (chytré čtení, hydrataci, identity mapu…), ale srdcem modelu zůstává ten čistě objektový model nějaké domény.

Pokud například máš checkboxy a podle jejich stavu při odeslání vytváříš nebo mažeš nějaké vazby, fakticky jde jen o správu nějakých asociací. A asociace není primárně doktrínovský pojem, asociace je primárně OOP pojem. Prostě nějaké objekty jsou (respektive nejsou) ve vzájemném vztahu. To jen doktrína umí namapované asociace sledovat a šetří ti práci tím, že změny v nich pro tebe umí promítnout do úložiště.

Promiň, že se pohybuji na tak abstraktní úrovni. :) Ale sama otázka je dost abstraktní. Možná kdybys vymyslel nějaké konkrétní zadání?

Editoval Tharos (14. 9. 2016 17:11)

newPOPE

@tharos na to ide dobre. Abstrakcia v tomto pripade uplne pasuje. Ono ano je tazko toto riesit.

@Landsman ono ked si precitas predmet „Zpracování formuláře pomocí Doctrine“ tak ked sa nad tym zamyslis tak ti dojde ze chces spajat 2 hranice.

formular, ten je sucastou UI
Doctrine, ta je len a len nastroj na persistovanie dat.

Ide o to, ze tam je presne este ten Model a ten si bohuzial musi vytvorit kazdy podla zadania, podstaty problemu ktory riesi, aplikacie, domeny…

Ak si este necital tak doporucujem https://leanpub.com/ddd-in-php/ su tam krasne a jednoducho veci popisane. Precitas to tak za vecer pripadne den, a ked si parkrat precitas po sebe napr. vo vlaku tak veci budu jasnejsie.