Zkusím poslat svůj názor na pojem Controler a jak si ho vykládám a
používám já, bez ohledu na podporu v různých frameworcích. Zároveň
nechci tvrdit, že ten můj pohled je správný, prostě s ním jen takto žiju
a zdá se mi to zatím docela funkční :).
Můj pohled na aplikaci vychází z pojmu Use Case (UC) - jeden nějaký
případ užití aplikace - založení objednávky, vyskladnění zboží,
apod. Tento UC má typicky nějaký začátek a řadu alternativních toků,
které mohou znamenat i výce způsobů jak ukončit jeho běh (dokončím vše,
opustím to přes cancel, opustím ho přes menu, apod.) . Mezi UC se dá
provádět navigace, přesně vím, kdy který začíná a kdy končí. Mohu ho
autorizovat, apod. (Myslím, že ve springu by se tomuto mohlo říkat Web
Flow)
No a když to implementuji, tak k jednomu UC dělám typicky jeden
Controler, který ho obsluhuje. UC se může skládat z více stránek (View)
- třeba wizardy, apod. Úkolem Controleru je obsloužit veškeré vstupní
požadavky z view - validovat vstupy, konvertovat vstupy, na základě
vstupů volat příslušnou business logiku (Model). Následně buď volí
View, kterým daná data vyrenderuje,nebo získá další (wizzard) a nebo se
na základě vrácených dat z business logiky rozhoduje o přechodu na jiný
UC (tedy i jiný controler) - tomu říkám Aplikační flow. A to řeším
tak, že ten Controler v případě přechodu na jiný UC prostě jen vyšle kód
toho nového UC a nějaký centrální handler provede ten přechod. - Tomu
se může říkat třeba FrontController. Takže já rozlišuji Application
Controller a FrontController - viz patterny.
http://www.corej2eepatterns.com/Patterns2ndEd/ApplicationController.htm,
http://www.corej2eepatterns.com/Patterns2ndEd/FrontController.htm
No a co se týče toho View - U mě View nesmí nikdy obsahovat logiku, jen
renderovat, proto taky nemám rád JSP, PHP a jiné podobné technologie,
ale člověk se musí uhlídat. Z pohledu funkčnosti se mi více líbí
technologie jako Freemarker, které nic jiného, než vypsání a formátování
dat na výstup neumožňují. A k tomu renderingu jak píšete - tak buď
bych to řešil tak, že controler volí jen logické označení view, které se
má použít - tedy řeknu - ShowFormXYZ a pak nějaký FrontControler,
ViewHandler, Filter, nebo jak chcete, na centralizované úrovni vybere
podle technologie klienta konkrétní realizaci view, třeba tak, že k
ShowFormXYZ přidá technologii: ShowFormXYZ_800x600.jsp to pouze v
případě, že opravdu logika je stejná pro všechny variace toho view.
V případě, kdy logika je jiná - například pro malé rozlišení by se šlo
na wizzard, kdežto pro velké rozlišení je vše v rámci jednoho formu -
bych asi už na frontControlleru rozstřelil podle klienta na různé
implementace obslužných AplikačníchControllerů.
A pak je tu ještě jedna možnost, použít tzv TwoStep view:
http://martinfowler.com/eaaCatalog/twoStepView.html
Controler vybere View, to view ale nerenderuje pro konkrétní
technologii, ale sestaví jakýsi metamodel-view - třeba popíše výslednou
obrazovku pomocí XML (XUL, XAML, XML-FO, jiné) a toto se pak teprve
transformuje podle technologie klienta do výstupu, takže třeba budete
mít různé transformace podle rozlišení obrazovky, apod. Takže pak to
neřeší controler, ale jakýsi renderovací procesor toho view.
Podle mě je vždycky MVC také otázka granularity pohledu, můžeme se
koukat na MVC s pohledu AJAXu, z pohledu serveru, z pohledu konkrétní
visuální komponenty. Možností je spousta, takže se těžko odpovídá na
podobné obecné dotazy. Jako zajímavé mi připadne řešení MVVM
http://en.wikipedia.org/wiki/Model_View_ViewModel.
S pozdravem
Petr
Dne 27.7.2011 14:33, Zdenko Vrabel napsal(a):
Mne neslo uplne o typovo rozne view-s. Toto uz myslim presahuje MVC.
Pri niecom takom, kedy uz clovek uvazuje o napriklad tej konzolovke a
tak sa uz budeme bavit v rovine backend | frontend (alebo to SEO).
Mozno som uviedol blby priklad ale zoberme si MVC v iOS (no flame).
Svojho casu to bolo jasne ako facka. Tie devices mali rovnake
rozlisenie obrazovky. Zrazu prisli tablety, obrazovka sa zmenila a
designeri mali silne nutkanie tuto plochu vyuzit. Funkcionalita sa
nemeni, len sa meni rozlozenie ovladacich prvkov. A teraz ci je dobre
mat nejaky obecny system na to alebo to s kludom moze riesit
controller a netreba tam pridavat dalsiu zlozitost. Podla mojho nazoru
sa MVC situuje vo frontende kde by controller mal riesit 'kliklo sa
na nejaky button' . View by to fakt mal len a len zobrazovat. Ja
osobne uz JSP povazujem za nie idealne, lebo clovek tam moze dat nieco
co tam nepatri (a castokrat tam aj da).
Mozete mi pls poslat link na vas clanok ohladom toho SOA?
Och asi strasne spekulujem ale kazdopadne dakujem za kazdy postreh.
Dakujem,
Zdenko
2011/7/27 Oto Buchta <[email protected] <mailto:[email protected]>>
Ono je to hodně složité. Při různých View (a myslím tím typově
jiných) je podle mého klasický model MVC trošku zavádějící.
To, co v takovém případě chceme, je mít obecný model, nad kterým
postavíme obecnou business logiku. Potom máme nějaké View, tedy
něco, pod čím rozumíme vlastní renderování. Business logika je pak
bude ovládána NĚČÍM, co se podle mne dá nazvat Controller
(minimálně ve Strutsech se tak opravdu jmenuje) přes obecné API,
ale co už renderování není. Něco, co rozhoduje, co se má zobrazit
příště. O tom, že je naprosto jiné ovládání aplikace pro Androida,
Web či z tlustého klienta je více méně jasné, ale přestoi bychom
spekulovat, že ono rozhodování, co bude dál, ale může být typicky
stejné pro celou aplikaci a že controller je tedy obecný a stejný
a že controllerem je ono generické API. Zásadní rozdíl ale nastává
ve chvíli, kdy si řekneme, že jedním z View bude také příkazový
řádek, že chceme aplikaci ovládat ze skriptu. Tím se z toho
skriptu stává do jisté míry controller. A nemyslím, že bychom
mohli tvrdit, že příkazový řádek pak má možnost pouze komunikovat
s modelem, tedy že máme zcela nový controller se stejným modelem.
Nikoli. Chceme komunikovat s onou Business logikou, volat její
SLUŽBY. Taktéž si nemyslím, že je skript ve stejné situaci
ovladače jako člověk, tedy že před ním stojí nějaké View, za ním
je controller a pak model.
Tím se dostáváme k dalšímu problému, tedy kde je MVC v SOA. Pak by
každá služba byla MVC sama o sobě. Ale o tom jsem už kdysi psal na
blogu.
2011/7/27 Zdenko Vrabel <[email protected]
<mailto:[email protected]>>
Dakujem za odpovede. Presne nieco taketo som potreboval
zistit. Mna zaujimal nazor viacero ludi ako to vidia. Ja
osobne nejdem sutazit :)
Zdenko
Dňa 27. júla 2011 10:25, Dusan Msk <[email protected]
<mailto:[email protected]>> napísal(-a):
Tiez nadobudam ten pocit. Nevidim dovod, preco by view
nemohol vybrat
controller. Je to na jednom mieste, nemusi sa to patlat
tonou xml
konfigurakov filtrujucich cosi kdesi z kadesi. Je mozne,
ze v urcitych
pripadoch to tak moze byt vyhodne, ja osobne som si ale zatial
vystacil v kode v ramci controlleru.
--
Dusan
2011/7/27 <[email protected]
<mailto:[email protected]>>:
> Obcas mi pripada, ze to je soutez "Jak co nejvice vyber
konkretniho view
> zasmodrchat"
>
> NkD
>
>> Od: Petr Prikryl <[email protected]
<mailto:[email protected]>>
>> Komu: [email protected] <mailto:[email protected]>
>> Datum: 27.07.2011 09:48
>> Předmět: Re: Otazka ohladom MVC
>> Odeslal: [email protected]
<mailto:[email protected]>
>>
>> Dobry den,
>> myslim si ze view by nemel vybirat controller, ale
nejaky filtr na
>> requestu a mam takovy pocit ze to v spring MVC dokonce
takto je, ze jde
>> podle urcitych pravidel urcit jaky filtr se aplikuje.
>> Dale me v tom navadi to, ze se kontroluje
accepted-content-type takze
>> snad se i takovy princip castecne pouziva (ikdyz toto
je jakoby na
>> jinou vrstvu).
>>
>> PP
>>
>> On Wed 27 Jul 2011 09:40:30 AM CEST, Zdenko Vrabel wrote:
>> > Dobry den,
>> >
>> > Moju otazku by som chcel smerovat skor k MVC patternu
ako ku Jave
>> > samotnej tak snad to nebude vadit. Ak sa nahodou tiez
budem pytat
>> > somarinu, tak ma ospravedlnte ale potreboval by som
sa len proste v
>> > niecom uistit alebo naopak aby mi niekto povedal ze
je to somarina.
>> > Totizto nedavno som premyslal nad MVC patternom (pre
web). Totizto
>> > zaujimalo by ma, ci je spravne/nespravne ak v
kompetencii controllera
> je
>> > rozhodovat o tom aky view sa pouzije alebo naopak.
Mal by controller
>> > vobec nieco vediet o viewoch? Vysvetlim na priklade.
V dnesnej dobe sa
>
>> > dostavaju do popredia rozne iPhony, Androidy, iPady a
neviem co. K
> tomu
>> > sa zacina aj prisposobovat design niektorych webov.
Ide o to, ze dajme
>
>> > tomu design pre iPad je nieco uplne ine ako design
pre klasicky
> browser
>> > (z pohladu web designera). To ma privadza k tomu, ze
je potrebne
> riesit
>> > aky view sa na zaklade User Agenta pouzije. Moja
otazka je vlastne o
>> > tom, ci je spravne mat v ramci MVC nejaky mechanizmus
routingu a
>> > Controller by do toho nemal zasahovat (v podstate len
produkuje model)
>
>> > alebo naopak. Takyto mechanizmus znecistuje MVC/
zvysuje jeho
> zlozitost
>> > a toto by mal riesit prave controller. Alebo je to
uplne jedno? Este
>> > doplnim ze hovorim o MVC vseobecne nie o nejakom
konkretnom ako Spring
> MVC.
>> >
>> > Za odpovede vopred dakujem,
>> > Zdenko Vrabel
>>
>>
>
>
--
Oto 'tapik' Buchta, [email protected] <mailto:[email protected]>,
http://tapikuv.blogspot.com
--
Petr
