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

12

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.

markmnl
fonte

Respostas:

9

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).

Joseph
fonte
"Nenhum código ... sempre" é uma regra ... regras são feitas para serem quebradas nas situações certas
WernerCD
1

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.

nlawalker
fonte
1

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.

Jay
fonte
1

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.

Desenhou
fonte
2
De acordo com essa lógica, também podemos implementar tudo em código simples novamente.
Steven Jeuris
@ Steven Jeuris De certa forma, isso seria preferível a uma mistura dispersa de xaml e código. Eu já vi isso feito puramente em código e trabalho.
Drew
De uma perspectiva pura de programador, eu concordo. Mas o problema é que o XAML permite o fácil desenvolvimento de ferramentas que podem ser usadas pelos designers, completamente separadas do código.
Steven Jeuris
@ Steven Jeuris: concordo plenamente. Eu faço tudo no xaml sempre que posso. Foi isso o que eu quis dizer quando disse no post: "Eu vim tratar o code-behind como último recurso". Estou tentando argumentar que menos code-behind é quase sempre melhor. Meu objetivo era dizer que o xaml puro é o melhor, mas, como a maioria dos princípios de design, não há problema em comprometer e invadir o code-behind em situações raras.
Desenhou
1

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).

back2dos
fonte