Perché avere un codice utente / scritto a mano e fare tutto in XAML?

Non ho mai sentito nessuno suggerire di mettere tutto in XAML.

In effetti, sarebbe una pessima idea, IMO.

Il problema, storicamente, proveniva dalle app di Winforms con la logica nel codice che non apparteneva lì, perché era logic . Ecco da dove viene l'importanza della VM. Permette di isolare le parti che collegano la vista al modello.

Pertanto, la vista è in grado di gestire solo ciò che funziona meglio, ovvero l'interfaccia utente.

Ora, se vi capita di avere situazioni in cui la vostra interfaccia utente richiede il codice, quindi con tutti i mezzi, andate a prenderlo e inseritelo nel codice. Tuttavia, direi che per il 95% degli scenari là fuori, è molto probabile che sia meglio lasciare l'interfaccia utente nel file di markup, e se hai bisogno di un po 'di codice, è probabilmente una logica che stai cercando di scrivere questo è più appropriatamente lasciato al View Model. Eccezioni a questo sono cose come i Behaviors, ma sono completamente separati, e richiedono un posto speciale (cioè non nel codice dietro).

Per rispondere direttamente alla tua domanda e assumendo che quando dici "codice" che in ogni istanza ti riferisci specificamente a code-behind (codice che si trova su una classe di controllo visivo), il motivo è che l'interfaccia utente può essere interamente implementato e manipolato in Blend, utilizzando una sola tecnologia. Il presupposto è che i progettisti di UX non sono sviluppatori e non vogliono lavorare nel codice, e che sono esperti di layout e XAML rispetto agli esperti di codifica. Se implementi tutto senza code-behind, puoi dare a quei tipi di designer gli strumenti di cui hanno bisogno per lavorare interamente nella loro lingua.

Fornisce una netta separazione tra programmazione imperativa e design dichiarativo.

È la ragione trainante per l'esistenza di "comportamenti" in Silverlight e WPF - invece di impadronirsi del codice nel code-behind, rendere un comportamento un suo piccolo modulo riutilizzabile. Se lo fai, Blend ti dà il vantaggio di essere letteralmente in grado di trascinarlo su un controllo. Ora, invece di avere una parte commovente one-off a un controllo all-in-XAML altrimenti, hai riassunto le parti in movimento in un bel contenitore che può essere manipolato utilizzando strumenti di progettazione.

Secondo la mia esperienza, questo spesso si riduce al tentativo di usare la logica complicata nei trigger XAML per tenerlo fuori dal code-behind, quando l'approccio migliore e più semplice sarebbe quello di non mettere questa logica in nessuno dei due - appartiene nel modello di visualizzazione.

Uno dei maggiori vantaggi nel fare tutto ciò che puoi in xaml è che mantiene tutto il comportamento in un unico posto. Ogni volta che lo sviluppatore deve saltare tra l'xaml e il codice diventa più difficile capirlo.

Sono stato in una squadra del WPF che non ha ridotto la priorità del codice. Ci sono state più di alcune volte che il debugging era molto più difficile perché alcuni gestori di eventi stavano manipolando il controllo e non era immediatamente evidente perché il comportamento era sparso in due file.

Detto questo, credo che abbia ragione a pensare che a volte si stia meglio compromettendo il principio di progettazione. Alcune cose sono molto difficili da fare in xaml. Ho passato ore o persino giorni cercando di far funzionare un comportamento in xaml che avrei potuto fare in molto meno tempo usando code-behind. Sono venuto per trattare il code-behind come ultima risorsa, ma non direi mai a qualcuno che non dovrebbero mai usarlo. È solo un altro compromesso che un buon ingegnere deve capire.

modifica: dai commenti sembra che il mio post venga interpretato come un argomento contro xaml. Il mio intento era di argomentare il contrario. Xaml puro è sempre preferibile perché mantiene tutto il comportamento in un unico posto. Un mix di xaml e code-behind può essere complicato, quindi ridurre al minimo code-behind è l'ideale. Xaml è preferibile al puro code-behind per molte ragioni. WPF e Silverlight sono progettati per essere scritti in xaml.

Ho solo una conoscenza molto superficiale di XAML, ma mi sconcerta che il compilatore non rileverà errori di battitura.

La differenza fondamentale è che XAML è dichiarativo , mentre C # è imperativo.

In poche parole:

Pane p = new Pane(200, 100);
Button foo = new Button("foo");
Button bar = new Button("bar");
p.addChild(foo);
p.addChild(bar);

vs.

<Pane width="200" height="100">
    <Button label="foo"/>
    <Button label="bar"/>
<Pane>

Il codice superiore crea davvero una gerarchia per effetti collaterali, mentre quella inferiore semplicemente lo dichiara. Vale anche la pena notare che, mentre per esempio il metodo addChild potrebbe essere rinominato, la relazione genitore-figlio è al centro del modello semantico ed è rappresentata proprio come tale nel frammento dichiarativo. È molto lontano dall'implementazione, che consente una grande ottimizzazione al di sotto, come l'istanziazione pigra, in modo completamente trasparente.
La programmazione dichiarativa ha una serie di vantaggi. È più conciso, espressivo e molto vicino al tuo modello. Andrei per quanto è preferibile.

Tuttavia, questo non significa che dovresti provare a inserire tutto in XAML. C # ha molti costrutti di alto livello che consentono uno stile dichiarativo.

Alla fine, vuoi che il tuo codice sia breve e di facile lettura. Quindi se riesci a ottenere la stessa cosa in C # con meno codice rispetto a XAML, usare C # è logico. Tieni presente che, tuttavia, il codice XAML è più "portatile" nel senso che è molto meno vulnerabile alle modifiche apportate ai componenti utilizzati, allontanando il framework .NET (ad esempio i dettagli di come vengono implementati i binding).