Best practice WPF: i controlli personalizzati funzionano correttamente con il design MVVM?

Stavo cercando di creare un controllo comune che potrò riutilizzare sulle mie pagine: un AddressControl che ha Indirizzo1, Indirizzo2, Città, Stato, Zip, ecc ...Best practice WPF: i controlli personalizzati funzionano correttamente con il design MVVM?

Originariamente ho appena creato una classe (AddressEntity) che conteneva tutti questi elementi e implementato INotifyPropertyChanged. Ho incluso quella classe come DependencyProperty nel mio Code-Behind per AddressControl e l'ho usata come DataContext per i binding alle sue proprietà.

Quindi, qualcuno ha detto che il mio codice era brutto e dovrei esaminare MVVM. Guardando la cosa, suppongo che:

AddressEntity.cs sarà solo un contenitore di dati (per esempio Address1, address2, etc.) ed i membri (cioè Clone, ToString, etc.)
ho bisogno di qualche AddressViewModel per avvolgere il mio AddressEntity e fornire le modifiche PropertyNotification, convalida, ecc.
Ho bisogno di avere una "vista" per questo.

Il problema è ogni esempio che abbia mai visto ha un UserControl come View e non un CustomControl. Prima di approfondire questo ...

È possibile utilizzare MVVM + controlli personalizzati per questo esempio?
È praticamente la stessa cosa (UserControl vs CustomControl) come la visualizzazione ad eccezione delle differenze primarie di UserControl vs CustomControl? Fondamentalmente, il mio CustomControl è davvero solo una vista?

Riferimenti: The Model-View-ViewModel (MVVM) Design Pattern for WPF

fonte

2010-08-16 m-y

Le due risposte che seguono sembrano essere in contrasto con l'altro. Sono confuso ora ... soprattutto dal momento che la seconda risposta sembra più probabile, ma la prima risposta ha (finora 3 voti). –

Concordo con NVM. Ho anche sentito personalmente che Custom Controls e MVVM non possono andare bene insieme. Hai CC e UC nello stesso progetto ma non riesco a pensare di avere una VM per i miei CCwherea che hanno VM per UC ha senso. – akjoshi

@akjoshi Non vedo perché WPF e MVVM puri abbiano qualcosa a che fare l'uno con l'altro. In effetti, indipendentemente dal controllo personalizzato o dell'utente, non è necessario utilizzare MVVM e direi che non devi utilizzare MVVM quando crei un utente o un controllo personalizzato. MA usando questi controlli allora sì, MVVM è un bel modo di usarli. Penso che sia facile distinguere tra "Ora faccio business logik e uso MVVM" e "Ora creo un controllo e non ho mai sentito parlare di mvvm". Ad esempio, abbiamo creato un controllo grafico completo con connessione a nodi, ecc., Che sono tutti controlli personalizzati, ma l'utilizzo di questo controllo avviene principalmente tramite viewmodels. – dowhilefor

CustomControls non vengono mai fatte con MVVM.

Quello che vuoi è una vista riutilizzabile (controllo utente) dei tuoi dati e non un controllo (controllo personalizzato).

UserControls e CustomControls sono due animali completamente diversi.

EDIT:

Nonostante il motivo per cui sono stati originariamente sviluppati controlli utente, in MVVM in genere si utilizza un UserControl quando si desidera una vista riutilizzabile, che è specifico per il vostro modello/ViewModel. È solo XAMl senza alcun codice dietro (eccetto per la roba InitializeComponent generata automaticamente). In genere si mantiene un UserControl nello stesso progetto che lo si utilizza in.

si va per un CustomControl quando si desidera un pezzo generico di funzionalità che richiede una vista e che ha potenziale utilizzo anche al di fuori della portata del vostro attuale applicazione. Qui il controllo è effettivamente definito in un file di codice e l'aspetto (che può essere ignorato) arriva tramite XAML in un dizionario di risorse. Generalmente si mantiene un CustomControl in un progetto ControlLibrary separato e si fa riferimento alla libreria nel progetto in cui si desidera utilizzarlo.

Con il dovuto rispetto a WallStreetProgrammer, scegliendo tra un controllo utente e un controllo personalizzato basato esclusivamente sul fatto o meno vuoi un controllo senza look è un po 'ingenuo.

fonte

2010-08-16 21:14:08 NVM

Sfortunatamente ci sono un paio di problemi aggiuntivi quando si tratta di User vs Custom Controls. Ad esempio, la gestione di ResourceDictionaries, se fatto male, può rendere Usercontrols praticamente inutile. Ma sono d'accordo, la scelta del controllo Utente o Personalizzato non dovrebbe essere fatta solo dalla mancanza di stile. – dowhilefor

Se i dizionari delle risorse non sono gestiti correttamente, è possibile rendere inutilizzabile l'intera applicazione: p. Ma cosa c'entra questo con la domanda? – NVM

Ovviamente hai ragione, ma usare un MergedDictionary in un controllo utente xaml è molto peggio, che usare un MergedDictionary sul tuo xaml in cui il tuo stile è memorizzato per il tuo controllo personalizzato (o il tuo generic.xaml). Ho imparato quel leason nel modo più duro. Per essere onesti, non vedo alcun motivo di utilizzare i controlli utente, ma questo è solo il mio parere personale. – dowhilefor

Quando si utilizza MVVM, Model e ViewModel non devono dipendere dalla vista, ovvero non devono preoccuparsi di quale tipo di visualizzazione li utilizza.

La differenza tra un controllo personalizzato e un usercontrol in WPF è che il controllo personalizzato è privo di look e può essere personalizzato tramite ControlTemplate. Questo è ciò che dovresti scrivere se stai scrivendo una libreria di controllo generica, come fa Microsoft. Se hai in mente un aspetto specifico per il tuo controllo, vai con un controllo utente, è molto più veloce ma avrà solo un aspetto, quello che definisci per esso.

È comune utilizzare una combinazione di controlli personalizzati e controlli utente in un progetto MVVM. Ad esempio, probabilmente utilizzerai una serie di controlli personalizzati di Microsoft (come caselle di testo e blocchi di testo) e li combinerai in controlli utente.

Vedi Control Authoring Overview

fonte

2010-08-16 21:45:45

Best practice WPF: i controlli personalizzati funzionano correttamente con il design MVVM?

risposta

Problemi correlati