Devo mantenere Business Objects separato dall'interfaccia utente in WPF?
Domanda
Il modo di fare le cose orientato al modello di visualizzazione di WPF rende molto allettante l'utilizzo di oggetti business nell'interfaccia utente. Hai riscontrato problemi con questo? Perché o perché non dovresti farlo?
Soluzione
La guida dei team di prodotto di Microsoft (ad esempio, è quello che utilizza il team di Blend) è l'architettura Model-View-ViewModel, una variante del popolare modello MVC. Un buon punto di partenza è http://blogs.msdn.com /johngossman/archive/2005/10/08/478683.aspx . Ci sono anche buoni articoli del Dr. WPF su questo argomento.
Sostanzialmente, sostengono di creare un livello ViewModel che utilizza oggetti business compatibili con rilegatura, come ObservableCollection e simili.
Inoltre, se alla fine potresti passare a Silverlight 2, potresti voler tenere gli oggetti business fuori dal livello dell'interfaccia utente in modo da poter scambiare la tecnologia dell'interfaccia utente (fino a quando WPF e Silverlight diventeranno compatibili con il codice sorgente).
Altri suggerimenti
Immagino di vederlo sotto una luce diversa. Cerco di tenere il più possibile fuori dall'interfaccia utente in modo da poter utilizzare qualsiasi presentazione dell'interfaccia utente di cui ho bisogno (ad es. Web, WPF, WinForms). Maggiore è la logica aziendale nel livello di presentazione, più potrebbe essere necessario riscrivere in seguito se si esegue la migrazione verso un'interfaccia utente diversa.
Non è un problema avere oggetti business nell'interfaccia utente, purché tutto ciò che stai facendo sia visualizzarli . In altre parole, se si desidera modificare le proprietà di uno o eliminarne uno o crearne uno nuovo, è necessario inviare un messaggio al controller, al presentatore o qualsiasi altra cosa; e i risultati dovrebbero quindi essere aggiornati nella vista.
Quello che non dovresti fare è usare il metodo ToString
dei tuoi oggetti (o qualsiasi altro metodo o proprietà sui tuoi oggetti) per influenzare il modo in cui verranno visualizzati la vista. Dovresti usare DataTemplate
per rappresentare la vista dei tuoi oggetti. Se hai bisogno di una rappresentazione più complessa, puoi usare un IValueConverter
per cambiare l'oggetto nella sua rappresentazione visiva.
Non essendo un guru del WPF, non posso esserne sicuro, ma il solito motivo per separare M, V e C è che puoi testare il controller indipendentemente dalla vista e viceversa.
Niente che ti fermi, ovviamente, ma dovrebbe essere molto più testabile (cioè, unit test) se è separato. Il modello MVP, che di solito è quello promosso da MS, è più orientato attorno al presentatore (cioè il modulo WPF) che ha un maggiore controllo, e va bene anche così ....
A seconda dell'architettura dell'applicazione o del modo in cui si prevede di riutilizzare componenti e oggetti, è possibile scegliere un certo grado di indipendenza dall'interfaccia utente (in questo caso WPF).
Ecco un esempio della mia esperienza:
Ho lavorato un po 'con WPF, su un progetto relativamente piccolo, in cui il il livello aziendale era già definito, e dovevamo solo creare un utente interfaccia. Certo, l'interfaccia aveva definito regole e oggetti propri con cui stava lavorando e perché l'applicazione è stata definita solo per UX abbiamo scelto di creare il nostro oggetti specifici, principalmente per estensione
DependencyObject
(principalmente per i datiBinding
).Alcune persone potrebbero obiettare che non va bene usare oggetti di dipendenza perché loro non sono serializzabili (in realtà lo sono sono - a XAML), portano a dipendenza da WPF (il
System.Windows
) e alcuni altri argomenti. Anche,DependencyObjects
supportano altri opzioni, come proprietà associate e proprietà di dipendenza . Altri potrebbe piacere usare ad esempioINotifyPropertyChanged
se esso ha senso, e altri potrebbero dirlo tutti questi schemi non appartengono altro livello oltre all'interfaccia utente. (Se vuoi saperne di più ci sono alcuni buoni WPF associazione dati articoli nella libreria MSDN, comprese le migliori pratiche per perfomance e per l'interfaccia utente)
È un po 'brutto che Microsoft abbia scelto di aggiungere alcune delle chicche allo spazio dei nomi System.Windows
, anziché, ad esempio, al System.ComponentModel
dove secondo me avrebbero potuto essere più utili (fornendo tutti questi schemi importanti non solo a WPF ma a .NET Framework).
Naturalmente questo è solo l'inizio e molti di noi sanno che alla fine la cosa si evolverà nella giusta direzione. (Con il rischio di andare fuori tema: prendi ad esempio il framework silverlight 2.0. È stata una versione affrettata, con alcuni degli oggetti nel modello WPF mancanti e altri non al loro posto naturale.)
Alla fine, tutto dipende da te, dal tuo stile di programmazione, dalle tue decisioni sull'architettura e dalla tua conoscenza della tecnologia.
Se sembra più naturale farlo in un certo senso, rispetto al libro, pensa
perché dovresti
eperché non dovresti
prima di prendere qualsiasi decisione!