Forum Delphi.cz

Co se jinam nevešlo => Obecné => Téma založeno: pepak 20-11-2012, 13:29:57

Název: Model - View - Controller
Přispěvatel: pepak 20-11-2012, 13:29:57
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 (http://www.zdrojak.cz/clanky/uvod-do-architektury-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.
Název: Re:Model - View - Controller
Přispěvatel: Radek Červinka 20-11-2012, 15:53:49
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.
Název: Re:Model - View - Controller
Přispěvatel: pf1957 20-11-2012, 18:06:41
Mrkni na nejake clanky o architekture MVVM, tam vysvetluji, kam se jim v desktop aplikacich podel controller.
Název: Re:Model - View - Controller
Přispěvatel: 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.
Název: Re:Model - View - Controller
Přispěvatel: Mi.Chal. 20-11-2012, 21:59:49
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.

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.