Autor Téma: Model - View - Controller  (Přečteno 3911 krát)

Offline pepak

  • Padawan
  • ******
  • Příspěvků: 1558
  • Karma: 37
    • Pepak.net
Model - View - Controller
« kdy: 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, 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.

Offline Radek Červinka

  • Administrátoři
  • Padawan
  • *****
  • Příspěvků: 2982
  • Karma: 108
    • Verze Delphi: D2007, DXE + 2 poslední
    • O Delphi v češtině
Re:Model - View - Controller
« Odpověď #1 kdy: 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.
Embarcadero MVP - Czech republic

Offline pf1957

  • Padawan
  • ******
  • Příspěvků: 3291
  • Karma: 139
    • Verze Delphi: D2007, XE3, DX10
Re:Model - View - Controller
« Odpověď #2 kdy: 20-11-2012, 18:06:41 »
Mrkni na nejake clanky o architekture MVVM, tam vysvetluji, kam se jim v desktop aplikacich podel controller.

Offline pepak

  • Padawan
  • ******
  • Příspěvků: 1558
  • Karma: 37
    • Pepak.net
Re:Model - View - Controller
« Odpověď #3 kdy: 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.

Offline Mi.Chal.

  • Guru
  • *****
  • Příspěvků: 576
  • Karma: 25
Re:Model - View - Controller
« Odpověď #4 kdy: 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.