Il code-behind in WPF dovrebbe essere considerato parte della vista?

Question

Il code-behind in WPF dovrebbe essere considerato parte della vista?

#1 da (6 voti)
#2 da (0 voti)

1

Ho letto molti articoli su diversi pattern in uso con WPF e questo è qualcosa che non ho ancora capito: un file code-behind dovrebbe essere considerato parte della vista? come Conseguenza, se i file con codice sottostante possono essere autorizzati a utilizzare la conoscenza di elementi specifici nel markup?

Ho una serie di scenari in cui i controlli presenti in una vista sono influenzati dai dati nel modello di vista (ad esempio un pulsante per ogni elemento della lista). Attualmente, gestisco questo tipo di scenari nel relativo file code-behind. Per me, questo sembra un dettaglio di implementazione della vista e quindi parte di essa; un'altra vista dello stesso modello di vista potrebbe scegliere una casella di elenco di voci di elenco, ad esempio).

wpf mvvm

posta Andy Hunt 10.02.2013 - 16:35

fonte

2 risposte

0

È IS parte della vista! Hai mai notato che xaml.cs è una classe parziale ? Quindi sì, il tuo codice dietro lo sa e può usare elementi specifici della vista.

Personnamente faccio del mio meglio per stare lontano da questo e utilizzare MVVM, ma tutto dipende da quale applicazione stai creando.

risposta data 01.12.2013 - 10:55

fonte

Leggi altre domande sui tag wpf mvvm

Il pensiero concettuale orientato agli oggetti è qualcosa che costruisci con esperienza? [chiuso] Incorporando le pagine HTML del web designer in un'applicazione MVC4

score 6 · Accepted Answer

Lo XAML e il codice dietro rappresentano la vista , ovvero la rappresentazione visiva di ViewModel. Un sacco di volte gli strumenti e i metodi disponibili in XAML (ovvero le dichiarazioni di associazione dei dati con i formattatori e tutti i modelli necessari) sono sufficienti per controllare il layout in modo soddisfacente e quindi il codice non è necessario o può essere vuoto.

Tuttavia, mi sono imbattuto in situazioni prima in cui presentare i dati come voglio utilizzare solo XAML e nessun codice è un vero ostacolo. In queste situazioni, se è più naturale generare i controlli dell'interfaccia utente nel codice sottostante, esegui . È essenzialmente solo un modo diverso di definire la tua vista (cioè nel codice procedurale piuttosto che in XAML dichiarativo).

I have a number of scenarios where the controls which are present in a view are influenced by data in the view model (eg a button for each list item). Currently, I handle these kinds of scenarios in the relevant code-behind file.

Se capisco la situazione correttamente, allora penso che in WPF questo può e dovrebbe essere fatto con DataTemplates e DataBinding in XAML, quindi non c'è bisogno di usare il codice dietro il file.