Model View Controller le origini

C’è un pò (tanta) confusione intorno ai pattern di separation of concerns.
Con i seguenti post provo a chiarire e spero di non aprire dei dibattiti infiniti.
Il primo pattern che andrò a spulciare è quello che potremmo definire: classic MVC
Com’è possibile anche leggere da Wikipedia, questo pattern nasce nel 1979 grazie ad un’idea di Trygve Reenskaug il quale lavorava su Smalltalk.
L’idea alla base è quella di dividere i compiti delle applicazioni in layer, in modo tale da ottenere una chiara divisione tra il domain object e la sua rappresentazione, introducendo così il meccanismo denominato Observer-Synchronization, il quale permette di rappresentare in più punti della nostra applicazione lo stesso domain object senza che questo si preoccupi della sua rappresentazione.

I Layer

Model

Rappresenta il domain object. Può esser ricavata da uno o più DAL gestiti dall’applicazione, ciò significa che i suoi dati possono esser ricavati da un database, da un file xml, da un file testuale o da tutti e tre contemporaneamente.
Non esiste un rapporto 1-a-1 con il Controller o con la View.

View

Visualizza la Model. Può essere una Windows Form, una pagina ASPX, come può essere un file di testo o un file XML.
La View comunica direttamente con la Model.

Controller

Interpreta gli input dell’utente (mouse, tastierta etc), notifica l’input alla model e/o cambia la view con quella corretta.

Questa è l’immagine che ho trovato che meglio rappresenta questa logica:

Seguiamo l’immagine di sopra:

1. Il controller riceve un input da parte dell’utente
2. Se l’input è valido il comando viene girato alla model
3. La model cambia stato
4. La view riceve la notifica del cambio di stato
5. La view visualizza i dati della model

Ok, questa era l’implementazione classica, vedremo le altre implementazioni nei prossimi post.
Se volete altre informazioni fate riferimento pure alle msdn.
Ciao