Co se jinam nevešlo > Obecné

Model - View - Controller

(1/1)

pepak:
Pořád se nemůžu zorientovat v praktickém nasazení architektury MVC mimo prostředí webu. Třeba mi někdo dokážete poradit?

Jde mi zhruba o tohle: Řekněme, že mám tabulku jako zhruba uprostřed článku o MVC, jen možná radši udělanou v Delphi (na těch je to líp vidět). Model chápu jako ta ukládaná data, tzn. v tomto případě časovou řadu zisku, plus pravidla a logika za nimi ("průměrný zisk se spočítá jako..." nebo "počet prodaných kusů nesmí být menší než nula"). View je tam celkem pět - ta tabulka s čísly, plus čtyři různé grafy.

S čím se nějak nemůžu vyrovnat je Controller. Podle definic by to měla být část, která nějakým způsobem zachytí různé události, zpracuje je a řekne modelu (a případně i view), co má dělat. U webových implementací ještě jakž takž controller chápu (s významnými "ale"), ale u takovéhle Excelové tabulky mi přijde, že nemůže mít žádný pozitivní smysl - buď (*) bude sloužit jen jako umělá a v podstatě zbytečná mezivrstva mezi "tlustým" view (view řekne controlleru, "změň mi zisk za rok 2000 na 150", a ten to předá modelu - proč by tedy view nemohl rovnou říct modelu?) nebo (**) bude muset controller znát detailní implementaci všech views, aby mohl správně vyhodnotit, co uživatel chce (události "uživatel mi napsal do políčka X hodnotu Y" z tabulkového view a "uživatel popadl bod na grafu a přetáhl ho o kousek vedle" z grafového view jsou vlastně totožné - jde o změnu jednoho datového pole v modelu na jinou hodnotu; logické by mi ale přišlo, aby tuhle transformaci provedl view, protože právě view sám nejlíp ví, co v něm znamená "přetažení bodu" nebo "napsání čísla a odmáčknutí ENTERu" - tím se ale dostáváme do bodu (*), kde byl controller zbytečný). K čemu by tedy v téhle triviální aplikaci (jedna časová řada s několika způsoby jejího zobrazení a editace) sloužil controller?

K čemu by controller sloužil ve složitější aplikaci, pokud odmyslíme od "strojově měněných" dat a připustíme možnost změny jen ze strany uživatele? (Tzn. chápu smysl controlleru v okamžiku, kdy si například tahám každých 10 sekund z webu kurz akcií a potřebuju ho transformovat do svého datového modelu; ptám se ale na případ, kdy žádnou externí konektivitu nemám a kurzy se mi mění jen tak, že "cvičená opice" buší do klávesnice jak vzteklá, aby to stihla.)

Pozn.: Předpokládejme, že model je sám schopen nějakým způsobem notifikovat všechny aktivní views, že se mají překreslit - např. vzorem Observer, v Delphi asi nejspíš nějakým seznamem TNotifyEvent.

Radek Červinka:
Myslím, že právě databinding je dobrým příkladem v Delphi. Klidně se podívej na IObserver a následníky v System.Classes.pas. Více je to rozvinuté až v XE3. Teda aspoň myslím, že mluvíme o tom stejném - mi to připadá jako MVC architechtura.

pf1957:
Mrkni na nejake clanky o architekture MVVM, tam vysvetluji, kam se jim v desktop aplikacich podel controller.

pepak:
Upřímně řečeno, ani v MVVM nevidím moc důvod pro VM. Možná v nějakých extrémních případech, kdy budu chtít dělat opravdu hodně odlišné view, ale ani tam nevidím žádnou zásadní výhodu proti dobře navrženému rozhraní modelu.

Mi.Chal.:

--- Citace: pepak  20-11-2012, 20:27:28 ---Upřímně řečeno, ani v MVVM nevidím moc důvod pro VM. Možná v nějakých extrémních případech, kdy budu chtít dělat opravdu hodně odlišné view, ale ani tam nevidím žádnou zásadní výhodu proti dobře navrženému rozhraní modelu.

--- Konce citace ---

VM tam funguje i jako takový kompromis mezi modelem a view, obojí má trochu jiné požadavky na to, aby se s tím dalo dobře pracovat. Druhá věc je, že view by mělo nějak vědět o tom, že se model změnil, aby se dokázalo překreslit. To se třeba v .Net ve WPF řeší eventy volanými při změně property. Tyhle eventy ale zase moc nepatří do modelu, ten je na nic nepotřebuje.

Navigace

[0] Seznam témat