Tutti non fanno che parlare di questi pattern come se fossero la panacea di tutti i mali.
Molti si sentono dei guru spiegando questi pattern, ma dai risultati che si ottengono mi viene da chiedere: ma li hanno mai applicati a dei grandi progetti, realmente?
Anche perché non ho mai sentito parlare di quantità, cioè quanta parte del codice è realmente riutilizzabile.
Sono arrivato al 90% di una applicazione stand-alone basata solo in minima parte su database, ma centrata su elaborazioni e calcoli, realizzata in C# per .NET 2.0.
Visto che si parla già da tempo di .NET 3.0 e 3.5 o voluto seguire i consigli degli “esperti” e utilizzare i pattern MVC e MVP (a seconda delle form) in modo da poter passare da un’interfaccia WinForm a una WPF nel modo più indolore possibile.
Da bravo… architetto / progettista / sviluppatore 
, ho preso la mia applicazione e l’ho fatta analizzare da uno dei programmi in circolazione (Source Monitor vers. 2.3.6.1) per ottenere le metriche del codice.
Dei risultati ottenuti, riporto i seguenti:
|
|
UI
|
Core
|
Totali
|
|
Files
|
335
|
525
|
860
|
|
Lines
|
47.746
|
51.120
|
98.866
|
|
Lines %
|
48
|
52
|
100
|
Legenda:
· UI : View + Controller + Application;
· Core : Model + tutte le altre classi indipendenti dalla UI.
Dall’esperienza si evince che il “Controller” essendo vicino alla “View” ne è dipendente, cioè cambiando la View deve cambiare il Controller. Inutile farsi false illusioni, le UI sono così diverse le une dalle altre che se si vogliono sfruttare a pieno il Controller deve essere realizzato specifico per quella View (UI). Si osservino tutti i casi in cui si è cercato di riutilizzare il Controller (vedi: NSK) l’interfaccia risulta molto scarna (essenziale).
Da questi risultati si evince che metà del codice deve essere riscritto per passare da WinForm a WPF. 
A cosa sono serviti i Pattern MVP, MVC ? 
Vediamo gli aspetti negativi e positivi dei pattern in questione.
Negativi
1) se il fine è quello di riutilizzare quanto più codice possibile passando da un tipo di User Interface a un’altra (es. da WinForm a WPF); conviene dividere il codice in due parti (invece che in tre): uno dipendente dall’interfaccia grafica (View) e l’altro indipendente (Model). Il Controller (nell’MVC) può benissimo essere integrato nella View. Si eviteranno molte complicazioni.
2) L’architettura del codice è più complessa e la quantità di codice da scrivere aumenta! 
Quando il nostro fine era proprio quello di riutilizzarlo per scriverne di meno!
3) Alcuni dicono che si devono utilizzare questi pattern in modo che si possa testare la UI, ma siamo quasi all’assurdo! Il codice da scrivere per poter fare un test è così tanto che è molto più probabile che l’errore si trovi nel codice con cui si vuole testare piuttosto che in quello che si testa. Più semplice è utilizzare manualmente un debugger e si risparmia tempo e si evitano falsi allarmi di bug inesistenti dovuti al codice di test errato.
Positivi
1) I Controller possono essere organizzati in una gerarchia e quindi, una parte comune (classe base) può essere riutilizzata in altri Controller, avendo così la gestione dell’interazione riutilizzabile all’interno dello stesso progetto. Questo permette anche una gestione più standard e diminuiscono notevolmente il numero di bug dovuti alla gestione delle View.
2) Il 5% del codice dei Controller (quello delle classi base) può essere riutilizzato quando si cambia la UI.
In questo mio progetto, anche una parte del Model non è riutilizzabile cambiando interfaccia grafica; questo ha fatto si che il Model l’ho dovuto dividere in due parti, uno dipendente dalla UI e l’altro indipendente.
Questo capita nei progetti che non sono solo un trasferimento di dati da e vero un database, ma svolgono anche elaborazioni complesse da un punto di vista grafico.