|
| Pattern: MVP (Model View Presenter)... mito o realtà? |
Mito! :-(
Ho iniziato un nuovo progetto, di una certa dimensione (stimate 200.000 righe di codice in C#) e siccome c’è l’evoluzione tecnologica che galoppa, avevo intenzione di renderlo indipendente dall’interfaccia grafica (UI).
La cosa che sapevo di sicuro è che il progetto sarebbe girato sotto Windows, ma per essere lungimiranti avevo pensato di iniziare l’interfaccia in WinForm, ma poi di passarla quanto prima in WPF quando il designer per questo ambiente sarebbe stato maturo (solo con Orcas verso Ottobre 2007).
Tutti direbbero che, basta utilizzare uno dei seguenti pattern per non avere problemi:
MVC: Model View Controller;
MVP: Model View Presenter;
Presenter First;
|
|
Il View e il Controller interagiscono tra loro in modo tale che non risulta possibile riutilizzare il controller per una View diversa, in quanto, se utiliziamo tecnologie completamente diverse per la View, il modo d’interagire cambia profondamente. |
|
|
Stesso discorso del View e Controller del MVC si applica al View e Presenter del MVP. |
|
|
Stesso discorso dell’MVC e MVP si applica al Presenter First.
La differenza è che, questo pattern permette di riutilizzare le stessa View, all’interno della stessa tecnologia, per molti Model diversi.
Per esempi io ho utilizzato lo stesso Presenter e Model (Generico) per gestire tante View diverse, ma simili nel comportamento. |
Se lo scopo di chiunque cerca di utilizzare questi pattern è lo stesso del mio (facile sostituzione della UI), bene... si può facilmente dire che il beneficio che se ne ottiene è veramente minimo.
In base al tipo di applicazione che si vuole realizzare, il codice che è dedicato alle tre parti del programma è il seguente:
|
Applicazione |
View + Controller oppure
View + Presenter |
Model |
|
Scientifica |
70 % |
30 % |
|
Gestionale |
80 % |
20 % |
Siccome cambiando il View si deve cambiare anche il Controller (se le tecnologie sono molto diverse tip Web - WinForm), allora dal 70% all’80% dell’applicazione deve essere riscritta.
Per esperienza personale, un programma che deve implementare questi pattern richiede circa il 20% di codice in più. Praticamente non si ottiene nessun beneficio, in quanto dal 20% al 30% del codice viene riutilizzato cambiando la UI, ma siccome se ne scrive il 20% in più, quindi il beneficio ottenuto è minimo.
Nel 1997 portai un’applicazione scritta in linguaggio C++ da DOS a Windows; il 90% del codice fu riscritto. Anche perché, quando si utilizza un ambiente diverso per la UI, si tende a sfruttare maggiormente le caratteristiche migliori dell’ambiente sottostante.
Se poi si pensa che per poter gestire questi pattern, gli sviluppatori devono essere di un livello medio-alto (anzi direi alto), direi che il rischio non vale la candela!
Se poi lo scopo, invece, è quello di: avere un’architettura strutturata meglio, i benefici secondari che si ottengono sono tanti (codice più chiaro, meno bug, manutenzione del codice più semplice ecc.). |