MVC a 3-vrstvá architektura

[Shampoo]

Ještě bych chtěl upozornit, že to, že data vezme Model componenta formuláře jsem myslel, vlastnosti (které např. uživatel administrace zadal), ale ne data, které zadá do formuláře následně uživatel - tyto hodnoty se předají presenteru, které je např. zadá do té konkrétní akce, která se má zavolat.

[Reklama]

[Shampoo]

Nevěděl jsem, co je to anemický model, viz. http://www.dagblog.cz/2009_10_04_archive.html

Ve zkratce, že modelové třídy neobsahují žádnou business logiku a veškerá funkčnost je v services, či controller/presenter.
A to je špatně, jelikož modelové třídy popisují business entity/objekty aplikace, tak by měla být i business logika dané entity v této třídě.

Tedy => Model obsahuje business logiku

[Kit]

Model - Formulář má nějaké vlastnosti - kolik textboxů tam je (souřadnice), jednotlivá tlačítka atp. (zde může být např. obecná validace), data může Model získat např. z databáze, nebo nějakého souboru atp.)

Vlastnosti formuláře bych do Modelu nedával - mám je v samostatné konfiguraci v XML, odkud si je výstupní šablona umí sama vytáhnout, aniž by tím obtěžovala Model. Ten má na starosti persistenci dat aplikace, aby ji dokázal správně delegovat.

Lze tedy vyměnit View, aby se na základě Modelu vykresloval nějak jinak a při změně vlastností konkrétního formuláře (třeba změna volání akce jiné modelující třídy, nebo třeba úplně upravit validaci), tak zbytek neovlivní. Na funkčnost

Je to tak?

View určuje co a jak se bude vykreslovat, Model mu jen na přání poskytuje aktuální data. View nemusí být jediný, může být zaměnitelný za jiný View.

Model může poslat do View oznámení, že se data změnila, pokud se View u něj registruje jako abonent. Často se to dělá i formou callbacku. View si pak potřebná data z Modelu vytáhne a zobrazí.

[perceptron]

A to je špatně, jelikož modelové třídy popisují business entity/objekty aplikace, tak by měla být i business logika dané entity v této třídě.

vy sice mozete tvrdit ze je to zle... ale je to pattern ktory je v java webovych veciach uplne bezny. a mozete tvrdit ze java libraries to maju zle ale sa to pouziva vyse 10 rokov. anemicky model je sice vraj velke fuj fuj fuj ale v takej jave neviete az tak dobre urobit domain driven development

napr. stare struts ma model ktory sa vie vyrenderovat do html alebo do pdf. model ostava rovnaky: menite len vystup.

model moze ale nemusi byt priamo business trieda: controller moze vytiahnut bussiness triedy zo servisnej vrstvy ale moze ich namapovat na modelove triedy ktore sa poslu do viewu. realna situacia je ked mate vo viewe nieco co prezentuje data z dvoch buziness objektov. kontroler oba objekty vytiahne + spoji + posle do viewu.

tak isto naopak: z formulara vam pridu data v podobe modelu a controller model premeni na business triedu.

[Kit]

model moze ale nemusi byt priamo business trieda: controller moze vytiahnut bussiness triedy zo servisnej vrstvy ale moze ich namapovat na modelove triedy ktore sa poslu do viewu. realna situacia je ked mate vo viewe nieco co prezentuje data z dvoch buziness objektov. kontroler oba objekty vytiahne + spoji + posle do viewu.

Tohle je popis MVP. Tady se však bavíme o MVC, ve kterém controller nemá přímý přístup do view, tedy mu ani nemůže poslat dva objekty. View si je klidně může z modelu vytáhnout sám - controller k tomu vůbec nepotřebuje.

[Reklama]

[Filip Jirsák]

Lze tedy vyměnit View, aby se na základě Modelu vykresloval nějak jinak

Myslím, že více View pro jeden model je dokonce velmi běžné. Potřebujete jeden View pro editaci (formulář), a typicky budete mít jiný View pro zobrazení daného modelu (bez editace).

A to je špatně, jelikož modelové třídy popisují business entity/objekty aplikace, tak by měla být i business logika dané entity v této třídě.

Špatně by to bylo jedině tehdy, pokud byste vyžadoval přísně objektovou architekturu aplikace. Jenže tak se dneska prakticky neprogramuje, mimo jiné by vám s objektovou architekturou nefungovala spousta návrhových vzorů (třeba právě MVC nebo vícevrstvá architektura). Programuje se v objektových jazycích a pracuje se s objekty, ale architektura není objektová. Třeba právě v MVC je Model jen datová struktura bez jakéhokoli kódu (zapomeňte teď, že je to často realizováno pomocí getterů a setterů, tedy výkonného kódu – z hlediska architektury je to jen strukturovaná paměť, která neumí nic dělat, jenom si pamatuje data), View a Controller zase představují výkonný kód, který nad těmi strukturami pracuje (a často se pro ně používá anti-pattern singleton, tedy nemají žádný vnitřní stav, je to jen kód).

To je možná příčina vašeho zmatení – všude se říká, že se dnes programuje v objektových jazycích, ale už se neříká, že se sice programuje s objekty, ale objektového kódu je v aplikacích spíš menšina, většina kódu je klasicky rozdělena na struktury a výkonný kód – i když jak ty struktury tak ten výkonný kód je implementován pomocí objektů.

[Kit]

Programuje se v objektových jazycích a pracuje se s objekty, ale architektura není objektová. Třeba právě v MVC je Model jen datová struktura bez jakéhokoli kódu (zapomeňte teď, že je to často realizováno pomocí getterů a setterů, tedy výkonného kódu – z hlediska architektury je to jen strukturovaná paměť, která neumí nic dělat, jenom si pamatuje data), ...

Můj Model je přísně objektový. Nemá žádný getter, setter ani veřejný atribut. Je důkladně zapouzdřený a veškerá komunikace s ním je pouze prostřednictvím injektované servisní vrstvy do některé z jeho (typicky pěti) metod.

[Shampoo]

Třeba právě v MVC je Model jen datová struktura bez jakéhokoli kódu (zapomeňte teď, že je to často realizováno pomocí getterů a setterů, tedy výkonného kódu – z hlediska architektury je to jen strukturovaná paměť, která neumí nic dělat, jenom si pamatuje data), View a Controller zase představují výkonný kód, který nad těmi strukturami pracuje...

To se mi nějak nezdá, můžete se odkázat na nějaký zdroj, kde je přímo napsáno, že Model je v MVC/MVP bez jakékoliv business logiky?

[Kit]

To se mi nějak nezdá, můžete se odkázat na nějaký zdroj, kde je přímo napsáno, že Model je v MVC/MVP bez jakékoliv business logiky?

Anemické modely jsem kdysi také dělal, protože mi to někdo poradil. Později jsem z toho vyrostl. Tím si asi musí projít každý vývojář.

Ve třetím dílu seriálu https://www.zdrojak.cz/clanky/alternativy-k-mvc-a-zaverecne-poznamky/ jsou na konci zdroje, ve kterých můžeš najít odpovědi na své otázky.

[perceptron]

kit, priklady?

k hlupemu mvc: pisal som vyssie. spring mvc. strutsy.
A Controller is typically responsible for preparing a model Map with data

[Filip Jirsák]

To se mi nějak nezdá, můžete se odkázat na nějaký zdroj, kde je přímo napsáno, že Model je v MVC/MVP bez jakékoliv business logiky?

MVC ani vícevrstvá architektura nejsou nějaké teoretické modely s exaktní definicí. Je to označení něčeho, co se v praxi používá – aby si vývojáři nemuseli dlouho vysvětlovat, o co jde, prostě jen řeknou ,,MVC", a tím jsou dané hrubé obrysy. V praxi ale můžete najít  implementace, kde v modelu v MVC opravdu žádná logika není (a ten model je implementován třeba čistě pomocí mapy klíč–hodnota), tak implementace, které business logiku zatahují i do modelu v MVC. Ale to už je pak porušeno oddělení vrstev, protože část business logiky, která má tvořit samostatnou vrstvu, taháte do prezentační vrstvy. Není to ale vůbec neobvyklé, dokonce pro to vzniká celá řada podpůrných mechanismů, které mají zajistit to, aby ta business logika byla naprogramovaná jenom jednou a v prezentační vrstvě se použila pokud možno automaticky. Ostatně celé programování v JavaScriptu na serveru (např. Node.js) vzniklo právě proto, aby bylo možné sdílet kód mezi klientem a serverem, tedy aby se mohlo rozvolnit to přísné oddělení vrstev.

Nicméně ani z pohledu objektového programování není business logika v modelu úplně správně. Protože pak ty objekty modelu mají zároveň dvě různé funkce – jednak uchovávají nějaký stav a informují posluchače o jeho změnách, a vedle toho mají ještě tu business logiku. Někdy se to dělává tak (má to tak třeba knihovna JGoodies Binding pro javovský Swing), že máte objekty doménového modelu, které mohou implementovat i tu business logiku, a ty obalíte prezentačním modelem, který řeší ty změny stavů a například i rozeditované objekty.

[Kit]

Nicméně ani z pohledu objektového programování není business logika v modelu úplně správně. Protože pak ty objekty modelu mají zároveň dvě různé funkce – jednak uchovávají nějaký stav a informují posluchače o jeho změnách, a vedle toho mají ještě tu business logiku. Někdy se to dělává tak (má to tak třeba knihovna JGoodies Binding pro javovský Swing), že máte objekty doménového modelu, které mohou implementovat i tu business logiku, a ty obalíte prezentačním modelem, který řeší ty změny stavů a například i rozeditované objekty.

Takový model je pak nutné opět rozvrstvit na vrstvu servisní a persistentní. V modelu samotném pak nejsou žádná data, ale pouze odkazy na ně. Taková struktura se pak velmi dobře rozšiřuje i udržuje, protože rozhraní k takovému modelu se ve své podstatě už nemusí měnit - další metody už nepřibývají. To už je však jen krůček k DDD.

[perceptron]

rozhraní k takovému modelu se ve své podstatě už nemusí měnit

ako konkretne vyzera tych 5 metod vo vasom rozhrani?

ak Vas model nema ziadne gettre a settre a len priamo komunikuje so servisnou vrstvou, ako komunikuje vas view s vasim modelom ked nema ako?

dajte priklad kodu lebo toto je desata tema kde nieco sofistikovane tvrdite a nemate na to dokazy

[Kit]

rozhraní k takovému modelu se ve své podstatě už nemusí měnit

ako konkretne vyzera tych 5 metod vo vasom rozhrani?

Běžně mívám v modelu metody search(), seek(), add(), modify() a remove(). Zpravidla to úplně stačí. V parametru je pak uvedeno co a kde se má zjistit nebo modifikovat. Výstupem prvních dvou metod je messenger s požadovanými daty. Zbývající metody výstup nemají - jsou to povely.

A teď se ukaž, jak to děláš ty.

[perceptron]

paranoja z kodu u vas pretrvava :-)

takze vasa html template v php vola metody search, seek atd na modeli? co presne je "messenger s pozadovanymi datami"?

ako som pisal: ak robim v spring mvc tak tam mam blbe anemicke modely. to ale vobec nevadi lebo takyto blby modelovy object sa aj tak len pouzije ako definicia premennej v thymeleaf template. controller teda len prijima blby anemicky model alebo generuje blby anemicky model

ukazka je http://www.mkyong.com/spring-mvc/spring-mvc-hello-world-annotation-example/

ak je ui komplexne a este stale chcem byt serverside tak ideme smer java server faces a wicket ale tam uz je tazke hovorit o mvc