La ricerca di pattern e procedure (pattern and practices, mm mi ricorda qualcosa) per sviluppare rapidamente e in modo robusto applicazioni orientate ai dati con Wpf.
- L'architettura: M-V-VM
risolvere: Bisogna arginare la proliferazione del codice attraverso gli strati. - Accesso ai dati: Entity Framework
- DTO
usare i data transfert object solo per comunicazione fra componenti dislocate fra i servizi o anche per la comunicazione fra uno strato e l'altro?
Dto flat o strutturati? Poco o DTO? - DI: Unity
per iniziare, forse più semplice di MEF (non è richiesta la risoluzione runtime delle dipendenze) - Pattern&Practices? coì a prima vista sembra un carrozzone di un sacco di codice difficilmente attaccabile, vederemo...
Dove cominciare?
Il tutorial è disponibile come extension di VS2010, codice e tutorial integrati in un'unico progetto VisualStudio. In quattro iterazioni di uno stesso progetto si passa da un'applicazione WPF affrontata come si faceva con windows forms (ModelViewPresenter, comunque utile per capire come usare semplicemente i DataContext). Per poi integrare MVVM, databinding, command, unity, test, mock.
Una scorpacciata superficiale di tutto che però da un'idea della forma da dare alla propria applicazione.
Alcune cose da tenere d'occhio:
- usare Relay Command
- chiamre i messagebox tramite un servizio.
Ci si accorge poi che le idee chiave del tutorial (e quasi tutto il codice di infrastruttura) sono tutti presenti nel MVVM Litght Toolkit in Codeplex (direi che questo framework sarà di riferimento per il proseguo)
L'event aggregation è spiegato forse troppo sommariamente:
[il seguente post risponde alla domanda su come passare messaggi da una view all'altra]
Event Aggregation prima visione, e miglioramento successivo.
Validazione e Composizione della UI?
Cosa mi manca ancora?
- Validazione (l'applicazione è orientata ai dati)
- Navigazione fra le "pagine" (o window?)
- Composizione della UI (fermo restando che Prism è l'obiettivo a cui tendere un approccio più semplice/pragmatico potrebbe risolvere la questione in toto)
Come livello di complessità si torna un po' indietro rispetto agli esempi visti prima (d'altronde questo articolo è del 2009). Di Interessante si vede l'uso di IDataErrorInfo per la validazione e una soluzione semplice per caricare/sostituire sulla UI view differenti.
Da Tenere d'occhio
Fluent Validation!!!
Commenti