In questi giorni sto lavorando, o meglio, sto studiando il VMMV perche’ dovro’ a breve sviluppare una media applicazione in WPF e vorrei proprio farlo usando WPF, L2S e il VMMV.

Sto leggendo un po’ di articoli e ci sono alcune cose che vorrei sottolineare, perche’ ogni qual volta che si parla di un nuovo pattern salta fuori il guru della situazione, e spesso vedo delle vere e proprie fesserie scritte sui blogs.

  1. Inanzi tutto consiglio a tutti una visita al blog di Martin Fowler, specialmente a questo articolo: presentation model. Dico solamente una cosa, e’ del 2004 …
  2. Poi parliamo per un secondo del DataModel e del ViewModel. Mi sa che qui qualcuno sta facendo un bel minestrone.
    1. DataModel is responsible for exposing data in a way that is easily consumable by WPF.
    2. A ViewModel is a model for a view in the application. It exposes data relevant to the view.
  3. La view in questo caso e’ il file XAML. Se poi ci piace sprecare tempo possiamo anche creare un contratto (IView) e passarlo alla View (XAML) ma a quel punto stiamo mischiando MVP con MVVM.

Ok, a scuola mi hanno insegnato che 1+1 = 2 e che quindi il ViewModel e il DataModel NON SONO LA STESSA COSA! Ci tengo a precisarlo.

Non ha nemmeno senso implementare un data model (il vecchio dominio con le entities per farla breve) e poi spararlo direttamente alla view tramite il viewmodel … Il viewmodel non e’ la copia del dominio. Lo scopo di VMMV e’ quello di fare una applicazione dove la view non sa niente del dominio, il dominio non sa niente della view, e tramite il viewmodel, possiamo passare da WPF a Silverlight cambiando solo alcune righe di XAML. Se ViewModel e View PARLANO a casa mia e’ MVC, MVP o MDP (minestrone di patterns).

Credo che Josh Smith su MSDN spiega in maniera molto pulita quello che dovrebbe essere il MVVM, anzi direi che e’ proprio chiaro … http://msdn.microsoft.com/en-us/magazine/dd419663.aspx

Dove e’ il punto? Il punto e’ che in giro ci sono un sacco di post schifezza, dove vengono realizzate architeturre (semplici esempi) con 2 layer con la UI fatta a minestrone e il DAL che e’ anche il PRESENTER ma che e’ anche il SERVICE layer. La unit of work e’ andata a farsi benedire … per non parlare dell’ uso improprio di XAML. 

Se poi ci mettiamo dentro gli esempi di Silverlight e le RIA dove il per microsoft il DAL (Entitiy Framework) in questo caso, viene piazzato dentro l’ applicazione web vera e propria, beh … io non sono per niente daccordo (d’accordo) [non mi ricordo mai come si scrive!]