Por que ter um código mínimo de usuário / manuscrito e fazer tudo em XAML?

Eu sinto que a comunidade MVVM se tornou excessivamente zelosa como os programadores de OO nos anos 90 - é um nome impróprio que MVVM é sinônimo de código. Da minha pergunta fechada StackOverflow :

Muitas vezes me deparo com posts aqui sobre alguém tentando fazer o equivalente em XAML em vez do código por trás. A única razão é que eles querem manter o código por trás de 'limpo'. Corrija-me se estiver errado, mas não é o caso:

O XAML também é compilado - no BAML - e, em tempo de execução, deve ser analisado no código de qualquer maneira. O XAML pode potencialmente ter mais erros de tempo de execução, pois eles não serão detectados pelo compilador no momento da compilação - de grafias incorretas - esses erros também são mais difíceis de depurar. Já existe um código por trás - goste ou não InitializeComponent (); precisa ser executado e o arquivo .gics contém um monte de código, embora possa estar oculto. É puramente psicológico? Eu suspeito que são os desenvolvedores que vêm de um plano de fundo da Web e gostam de marcação em oposição ao código.

EDIT: eu não proponho código para trás em vez de XAML - use ambos - prefiro fazer minha ligação em XAML também - sou contra fazer todos os esforços para evitar escrever código por trás de esp em um aplicativo WPF - deve ser uma fusão de ambos para tirar o máximo proveito disso.

ATUALIZAÇÃO: Nem sequer é idéia da Microsoft; todos os exemplos no MSDN mostram como você pode fazer isso em ambos.

Eu nunca ouvi falar de alguém sugerindo colocar tudo em XAML.

De fato, seria uma péssima idéia, IMO.

O problema, historicamente, veio dos aplicativos Winforms com lógica em seu código por trás e que não pertenciam a ele, porque era lógica . É daí que vem a importância da VM. Permite isolar as peças que unem a Vista ao Modelo.

Portanto, a exibição é deixada para lidar apenas com o que é melhor, que é a interface do usuário.

Agora, se houver situações em que sua interface do usuário exija código, vá em frente e coloque-o em seu código. No entanto, eu diria que, para 95% dos cenários existentes, provavelmente será melhor deixar a interface do usuário no arquivo de marcação e, se precisar de algum código, provavelmente será uma lógica que você está tentando escrever que é deixado de maneira mais apropriada para o View Model. Exceções a isso são coisas como Comportamentos, mas são animais separados por completo e exigem um lugar especial (ou seja, não no seu código anterior).

Para responder diretamente à sua pergunta e supondo que, quando você diz "código", em todos os casos você está se referindo especificamente ao code-behind (código que está em uma classe de controle visual), o motivo é que sua interface com o usuário pode ser totalmente implementada e manipulado no Blend, usando apenas uma tecnologia. A suposição é que seus designers de UX não são desenvolvedores e não desejam trabalhar em código, e que eles são especialistas em layout e XAML, em vez de especialistas em codificação. Se você implementar tudo sem o code-behind, poderá fornecer a esses tipos de designers as ferramentas necessárias para que funcionem inteiramente em seu idioma.

Ele fornece uma separação limpa entre programação imperativa e design declarativo.

É a principal razão para a existência de "comportamentos" no Silverlight e no WPF - em vez de inserir algum código no code-behind, faça do comportamento um módulo pequeno e reutilizável. Se o fizer, o Blend oferece o benefício de literalmente ser capaz de arrastar e soltar em um controle. Agora, em vez de ter uma parte móvel única para um controle all-in-XAML, você abstraiu as partes móveis em um bom contêiner que pode ser manipulado usando ferramentas de designer.

Na minha experiência, isso geralmente se resume a tentar usar lógica complicada em gatilhos XAML para mantê-la fora do código, quando a abordagem melhor e mais simples seria colocar essa lógica em nenhuma delas - ela pertence à visão -modelo.

Uma das maiores vantagens de fazer tudo o que você pode no xaml é que ele mantém todo o comportamento em um só lugar. Toda vez que o desenvolvedor precisa pular entre o xaml e o código, fica mais difícil entendê-lo.

Eu estive em uma equipe do WPF que não fez da redução do código uma prioridade. Houve mais de algumas vezes que a depuração foi muito mais difícil porque algum manipulador de eventos estava manipulando o controle e isso não ficou imediatamente aparente porque o comportamento estava espalhado em dois arquivos.

Dito isto, acredito que você está certo ao pensar que às vezes é melhor comprometer o princípio do design. Algumas coisas são muito difíceis de fazer no xaml. Passei horas ou até dias tentando fazer com que um comportamento funcionasse no xaml, o que eu poderia ter feito em muito menos tempo usando o code-behind. Eu vim tratar o code-behind como último recurso, mas nunca diria a alguém que nunca deveria usá-lo. É apenas mais uma troca que um bom engenheiro precisa entender.

edit: a partir dos comentários, parece que meu post está sendo interpretado como argumentando contra o xaml. Minha intenção era argumentar o contrário. O xaml puro é sempre preferível, pois mantém todo o comportamento em um só lugar. Uma mistura de xaml e code-behind pode ser complicada, portanto, minimizar o code-behind é ideal. O Xaml é preferível ao puro code-behind por várias razões. O WPF e o Silverlight foram projetados para serem escritos em xaml.

Eu tenho apenas um conhecimento muito superficial do XAML, mas me surpreende que o compilador não detecte erros de digitação.

A diferença básica é que XAML é declarativo , enquanto C #, por exemplo, é imperativo.

Simplificando:

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>

O código superior realmente cria uma hierarquia por efeitos colaterais, enquanto o código inferior simplesmente a declara. Também é importante notar que, embora, por exemplo, o addChildmétodo possa ser renomeado, o relacionamento filho-pai está no centro do modelo semântico e é representado como tal no fragmento declarativo. Está muito longe da implementação, que permite muita otimização por baixo, como instanciação lenta, completamente transparente.
A programação declarativa tem várias vantagens. É mais conciso, expressivo e muito próximo ao seu modelo. Eu iria tão longe quanto é preferível.

No entanto, isso não significa que você deve tentar inserir tudo no XAML. O C # possui muitas construções de alto nível que permitem um estilo declarativo.

No final, você deseja que seu código seja curto e fácil de ler. Portanto, se você pode conseguir a mesma coisa em C # com menos código que em XAML, usar C # é lógico. Lembre-se de que, no entanto, o código XAML é mais "portátil" no sentido de que é muito menos vulnerável a alterações nos componentes usados, abstraindo a estrutura do .NET (por exemplo, os detalhes de como as ligações são implementadas).