In un costruttore per una finestra WPF, cosa deve succedere prima di InitializeComponent() e dopo?

Question

In generale, ho inizializzato le proprietà dello Window prima dello InitializeComponent() e dell'impostazione dei controlli contenuti in seguito. Tuttavia, non sono stato del tutto coerente, e non ho notato un problema con l'ordinamento. Quindi:

• Sono (potenzialmente) facendo qualcosa di orribile? In particolare, ci sono problemi con l'impostazione delle proprietà dei controlli figlio prima dello InitializeComponent()?
• Qual è il bello stile in questo senso?

Edit: Dato che le prime due risposte che ho ricevuto sono stati un po 'contraddittorio, mi permetta di essere più specifico:

public Foo Foo {get; protected set} 
public FooWindow (Foo foo) 
{ 
    Foo = foo; 
    this.Closing += FooWindow_Closing; 
    Foo.Frobbed += Foo_Frobbed; 

    InitializeComponent(); 

    this.DataContext = this; 
    this.Title = Foo.Name() + " Window"; 

    FooListView.ItemSource = Foo.CalculateList(); 

    FocusManager.SetFocusedElement(this, FooListView); 
} 

È questo circa la destra? Dovrei semplicemente fare MVVM e non avere nulla nel mio costruttore Window?

Answer 1

Chiamando InitializeComponents dopo qualche altro codice si corre il rischio di sovrascrivere accidentalmente le proprietà con elementi impostati in XAML o di utilizzare un oggetto non inizializzato. Di solito il code-behind è una priorità più alta rispetto a XAML, quindi lascerei InitializeComponents (ovvero, analizza e carica XAML) nella parte superiore.

Answer 2

Io di solito chiamo tutto ciò che non richiede l'albero visivo prima chiamo InitializeComponent().

Tutte le mie implementazioni utilizzano lo schema MVVM, quindi preferisco avere il mio ViewModel istanziato e popolato prima che l'interfaccia utente venga caricata sul client.

Se si carica sempre InitializeComponent() prima, si corre il rischio di creare un'esperienza utente cattivo, mostrando una visione disabitata che aggiorna improvvisamente contro uno che è popolata quando si entra in vista.

Answer 3

In risposta alle vostre domande specifiche:

Am I (potenzialmente) di fare qualcosa di orribile? In particolare, ci sono problemi con l'impostazione delle proprietà dei controlli figlio prima di InitializeComponent()?

È probabile che i controlli figlio non siano ancora disponibili nel codice finché non si chiama InitializeComponents. In genere sarebbe una cattiva forma farlo.

Qual è lo stile buono in questo senso?

Questa sarà una questione di gusti, ma in generale mi sento di raccomandare che se hai intenzione di sfruttare la separazione che XAML ti offre, la prenderei il più lontano possibile. Se stai facendo cose logicamente sull'interfaccia utente, prova a farlo in XAML. Non è tanto una cosa MVVM quanto una separazione della presentazione dalla logica. La maggior parte di ciò che hai nel tuo codice di esempio può essere fatto in modo dichiarativo, anche se solo attraverso ValueConverters.

E.g se Foo era DependencyProperty, quindi è possibile allegarlo anche in XAML e aggiungere i callback come parte del callback ValueChanged. Di nuovo, questo non è MVVM, ma è piuttosto fondamentale per WPF.

Per la maggior parte delle altre cose, in realtà è probabile che si desideri attendere fino a quando viene chiamato OnLoaded, anziché eseguire il lavoro nel costruttore.

Speranza che aiuta,