Devo mantenere Business Objects separato dall'interfaccia utente in WPF?

Question

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?

Answer 1

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).

Answer 2

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.

Answer 3

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.

Answer 4

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ì ....

Answer 5

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 dati   Binding ).

     

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 esempio    INotifyPropertyChanged 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 e perché non dovresti prima di prendere qualsiasi decisione!