MVC# è un ambiente che facilita l’implementazione, in ambiente .NET, di una architettura a tre livelli secondo il pattern MVP (Model-View-Presenter).
Gli autori nel presentare il loro lavoro (qui il sito ufficiale) ci introducono alle più o meno sottili differenze tra MVC (Model-View-Controller) e MVP, poi spiegano come quest’ultimo risolva parte della complessità del precedente e sia più adatto agli ambienti di programmazione odierni, giustificando così la loro scelta di implementare MVP, infine dichiarano che per il loro prodotto useranno la dicitura ‘controller’ anziché ‘presenter’ (da qui il nome MVC# e, a mio avviso, una certa confusione tra pattern e nomenclatura, ma tant’è!).
I concetti alla base del pattern sono pochi: ogni applicazione si compone di una serie di task (ovvero una serie di azioni che portano a termine un compito o risolvono un problema), ogni task comporta il coinvolgimento dell’utente e comunque il passaggio attraverso più interaction points, ognuno dei quali
- riceve ed elabora i datti immessi dall’utente
- inoltra le opportune richieste agli oggetti business
- interroga e/o modifica lo stato del task
- invia un feedback all’utente
Nell’ottica della semplificazione si associa ogni interaction point ad una vista (view) realizzata poi con una sola classe, alle spalle della quale ci sarà la corrispondente classe controller a realizzare lo strato applicativo e a dialogare con gli oggetti business (domain); prendo a prestito lo schema presente nel sito di MVC# per visualizzare graficamente il tutto:
Ora veniamo nello specifico al valore aggiunto di MVC#, che si propone appunto di semplificare l’uso di MVP da parte degli sviluppatori.
Per quanto detto sopra l’applicazione è organizzata in task: ebbene anzitutto ogni task della applicazione deve essere ‘avviato’, poi deve essere possibile navigare all’interno del task (ovvero effettuare transizioni attraverso i suoi interaction points), e da un punto di vista di User Interface deve essere possibile usare diverse piattaforme (web o Windows). Per il primo punto MVC# fornisce la classe TaskManager che espone un metodo
public ITask StartTask(Type taskType)
che crea un’istanza del task del tipo passato come parametro, una della classe TaskInfo che popola con le caratteristiche del particolare tipo di task richiesto e un’istanza della classe Navigator che associa al task per poi invocare il metodo OnStart() del task; la classe Navigator a sua volta fornisce il metodo Navigate(…) che consente il passaggio da un interaction point ad un altro appoggiandosi sulla classe ViewManager che ovviamente ha diverse implementazioni a seconda della piattaforma usata per realizzare la UI (MVC# si applica a UI realizzate con Winforms, asp.net Webforms, SIlverlight e .NET Compact Framework): il comportamento generale è sintetizzato in una interfaccia IViewsManager.
Ogni vista, poi, deve essere creata la prima volta che viene ‘navigata’ e pertanto la Classe ViewManager è in grado di avere, a partire dal tipo della vista, una classe ViewInfo (indipendente dalla piattaforma per la quale la vista è realizzata) popolata e una ViewInfoCollection alla quale aggiungere le viste nuove alla loro prima creazione; ad ogni creazione di una vista, poi, si ha anche l’associazione della stessa al suo controller: secondo quanto previsto da MVP infatti deve essere possibile accedere al controller dalla vista e viceversa.
Resta ancora un legame previsto da MVP, tra il controller e il task, perché deve essere possibile dal controller accedere al task per modificarne lo stato e per poter effettuare navigazioni tra i suo interaction points. Questo si realizza ancora per il tramite della classe Navigator responsabile di tenere i controller per i suo task e che espone il metodo GetController.
In poche parole in effetti l’ambiente risparmia la scrittura di tanto codice e permette di implementare il pattern MVP egregiamente. Noi lo abbiamo sperimentato con una UI Silverlight 2 e in effetti abiamo raggiunto una buona produttività in tempi brevi.