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

Sento che la comunità MVVM è diventata troppo zelante come i programmatori OO negli anni '90: è un termine improprio MVVM è sinonimo di nessun codice. Dalla mia domanda StackOverflow chiusa :

Molte volte mi imbatto in post qui su qualcuno che cerca di fare l'equivalente in XAML invece del codice dietro. La loro unica ragione è che vogliono mantenere il loro codice "pulito". Correggimi se sbaglio, ma non è il caso che:

Anche XAML viene compilato - in BAML - quindi in fase di runtime deve essere analizzato comunque nel codice. XAML può potenzialmente avere più bug di runtime in quanto non verranno raccolti dal compilatore al momento della compilazione - da errori di ortografia - anche questi bug sono più difficili da eseguire il debug. C'è già del codice dietro - piaccia o no InitializeComponent (); deve essere eseguito e il file .gics in cui si trova contiene un sacco di codice sebbene possa essere nascosto. È puramente psicologico? Ho il sospetto che siano gli sviluppatori che provengono da un background web e amano il markup rispetto al codice.

EDIT: non propongo codice dietro invece di XAML - uso entrambi - preferisco fare anche il mio binding in XAML - sono solo contrario a fare ogni sforzo per evitare di scrivere codice dietro esp in un'app WPF - dovrebbe essere una fusione di entrambi per trarne il massimo.

AGGIORNAMENTO: Non è nemmeno un'idea di Microsoft, ogni esempio su MSDN mostra come è possibile farlo in entrambi.

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

In effetti, sarebbe un'idea terribile, IMO.

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

Pertanto, la vista è lasciata solo per gestire ciò che è meglio, che è l'interfaccia utente.

Ora, se ti capita di avere situazioni in cui la tua UI richiede codice, allora provaci e inseriscilo nel tuo codice. Tuttavia, direi che per il 95% degli scenari disponibili, molto probabilmente sarà 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 che è più opportunamente lasciato al modello di visualizzazione. Eccezioni a questo sono cose come Comportamenti, ma sono animali completamente separati e richiedono un posto speciale (cioè non nel codice dietro).

Per rispondere direttamente alla tua domanda, e supponendo che quando dici "codice" che in ogni caso ti riferisci specificamente al code-behind (codice che si trova su una classe di controllo visivo), il motivo è che la tua interfaccia utente può essere interamente implementata e manipolato in Blend, usando solo una tecnologia. Il presupposto è che i vostri progettisti di UX non sono sviluppatori e non vogliono lavorare nel codice, e che sono esperti di layout e XAML invece di esperti di codifica. Se si implementa tutto senza code-behind, è possibile fornire 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 progettazione dichiarativa.

È il motivo trainante dell'esistenza di "comportamenti" in Silverlight e WPF - invece di inserire un po 'di codice nel code-behind, rendere un comportamento il suo piccolo modulo riutilizzabile. Se lo fai, Blend ti dà il vantaggio di poter letteralmente trascinarlo su un controllo. Ora, invece di avere una parte mobile una tantum su un controllo altrimenti completamente all-in-XAML, hai estratto le parti mobili in un bel contenitore che può essere manipolato usando strumenti di progettazione.

Nella mia esperienza, questo spesso si riduce al tentativo di utilizzare una logica complicata nei trigger XAML per tenerlo fuori dal codice, quando l'approccio migliore e più semplice sarebbe quello di non inserire quella logica - non appartiene alla vista -modello.

Uno dei maggiori vantaggi di fare tutto il possibile in xaml è che mantiene tutto il comportamento in un unico posto. Ogni volta che lo sviluppatore deve saltare tra xaml e il codice diventa più difficile capirlo.

Sono stato in un team WPF che non ha fatto della riduzione del code-behind una priorità. Ci sono state più volte che il debug 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 tu abbia ragione a pensare che a volte stai meglio a scendere a compromessi sul principio del design. Alcune cose sono molto difficili da fare in xaml. Ho passato ore o addirittura giorni a cercare di far funzionare un comportamento in xaml che avrei potuto fare in molto meno tempo usando code-behind. Sono arrivato a 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 una discussione contro xaml. Il mio intento era di discutere il contrario. Lo xaml puro è sempre preferibile perché mantiene tutto il comportamento in un unico posto. Un mix di xaml e code-behind può essere contorto, quindi è l'ideale minimizzare code-behind. 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 # per esempio è 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 quello inferiore lo dichiara semplicemente. Vale anche la pena notare che, sebbene ad esempio il addChildmetodo possa essere rinominato, la relazione figlio-genitore è al centro del modello semantico ed è rappresentata come tale nello snippet dichiarativo. È molto lontano dall'implementazione, che consente molte ottimizzazioni sottostanti, come un'istanza pigra, in modo completamente trasparente.
La programmazione dichiarativa presenta numerosi vantaggi. È più conciso, espressivo e molto vicino al tuo modello. Vorrei arrivare al punto che è preferibile.

Tuttavia, questo non significa che dovresti provare a dare un pugno a 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, l'uso di C # è logico. Tieni presente che, tuttavia, il codice XAML è più "portabile", nel senso che è molto meno vulnerabile alle modifiche nei componenti utilizzati, che allontana il framework .NET (ad esempio i dettagli su come vengono implementati i binding).