•  05-07-2019
  •  | 
  •  

Pergunta

Eu não gosto de usar XAML.Eu prefiro tudo código em C#, mas eu acho que eu estou fazendo coisas erradas.

Em que casos é melhor usar XAML e quando você usar o C#?Qual é a sua experiência?

Foi útil?

Solução

Criando uma janela inteira em C # pode ser uma bagunça de código. A melhor coisa sobre WPF é que XAML permite que você separe seu projeto de sua lógica, para fazer código muito mais fácil de ler.

Vou usar C # quando eu preciso para criar controles dinâmicos, mas tendem a manter a minha concepção geral, storyboards estáticos, estilos, DataTemplates, etc. em XAML.

Outras dicas

Confira este vídeo em MVVM em WPF. Se você quer quebrar a cabeça em torno de como organizar uma aplicação WPF vis-a-vis o que se passa em XAML, código por trás e outras abstrações, este é um ótimo lugar para começar.

Você certamente pode ir longe demais com XAML. Aqueles que querem toda a sua interface de usuário (incluindo lógica, relações manipulação de eventos, etc), definida no XAML são, provavelmente, perdendo o ponto.

O objetivo do XAML é fornecer um formato comum para determinar como as coisas deveriam olhar . Deve ser apenas uma descrição de como colocar as coisas, como cor e estilo-los visualmente.

Não há realmente muito pouco sentido em tentar usá-lo como um substituto para outros aspectos do C #, porque C # tem uma permanente vantagem inicial em termos de recursos de programação - reutilização (que definem tipos e funções), referindo-se variáveis, processual programação, e mesmo declarativas ou funcionais estilos.

Pessoalmente, eu realmente gosto de jogar juntos uma interface de usuário com uma expressão Linq!

O absurdo final foi alcançado por uma vi amostra onde costumavam ações de fluxo de trabalho como os filhos de um botão para fornecer o manipulador Click, por isso todo o programa estava em XAML. Soa "cool", mas o problema é que era significativamente mais feia e ilegível do que o equivalente C # ou programa VB.NET, e assim tudo o que está pronto para usar em C # tem de ser substituído por um mais detalhado, o equivalente escamosa. Nada foi realmente ganhou por esta tradução para uma sintaxe mais feio - é o mesmo programa só mais hediondo. XML é uma base fraca para a sintaxe de uma linguagem de programação geral. Comece com o fato de que o símbolo maior que tem de ser escrito como >!

Em um universo paralelo, a Microsoft lançou o C # 3.0 antes de terminar XAML. A equipe XAML adotada C # 3.0 objeto / lista inicializador sintaxe em vez de XML como sua sintaxe. E todo este debate nunca aconteceu.

A minha experiência é que algumas coisas são muito mais rápido do que fazer em C #, enquanto a maioria são mais rápidos que fazer em XAML. Quando se leva 5 linhas de código C # para fazer o que uma única linha de código XAML pode fazer, é muito fácil para mim para escolher o que é melhor.

Basicamente, o XAML é o significado para a expressão visual-design, C# é o significado para a expressão lógica.

Qualquer projeto visual deve ser feito em XAML, qualquer lógica deve ser implementado em C#.

- Isso permite dando o design visual para um designer para jogar sem se preocupar com a mudança para a lógica e, até mesmo, a substituição de todo o projeto visual em tempo de execução usando soltas XAML.

- Isso também significa que você pode substituir a lógica ou a visual-design sem "quebrar" qualquer um.

- A ligação entre os dois deve ser feito com ligações de dados e com o comando ligações.

A prática que eu uso é:

1.Definir o modelo de negócio modelo de objeto de dados) em separado de código C#.

2.Definir a constante de peças de exibição (a constante de partes da imagem gráfica do usuário a interface, por exemplo,o windows, menus, ...) em XAML (de preferência usar o Blend e não VS para isso).
* Não definir o estilo (cores, fontes, ...) aqui.
* Não escrever manipuladores de eventos para os botões (na maioria dos casos) em código-behind-the-XAML, use o comando-enlaces em vez disso.

3.Definir a forma como o modelo é apresentado na vista (GUI para visualização/edição de objetos de dados) usando o XAML "ResourceDictionary"s, localizado em arquivos separados.

- Escrever utilizando a mistura, em seguida, adicionar ligações para XAML utilizando o VS (Jetbrains' Resharper add-on para o VS irá ajudar com expressões de ligação).

- Se os tipos de objeto não são conhecidos durante o tempo de design, você pode usar "solta-o XAML" e coloque o XAML em uma pasta que pode ter arquivos adicionados e / ou editado dentro sem recompilar.

4.Criar uma conexão entre o modelo e o modo de exibição (um controlador/exibir modelo) em C#:
* Cria vistas como necessárias (para a dinâmica de objetos)
* Dados-liga-se o modo de exibição para o modelo (conjuntos de vista de origem de dados como o objeto relevante de acordo com o modelo)
* Implementa os comandos
* Comando-liga-se o modo de exibição para o comando de implementações dentro de si

5.No Aplicativo.xaml eliminar o StartupUri="MainWindow.o xaml" e adicionar Startup="ApplicaitonStartUp" em vez disso.
Dentro do ApplicationStartUp() manipulador de eventos:
* Carga solto-XAMLs você tem
* Criar o controlador de
* Criar a janela principal
* Criar o modelo de
* Ligar o controlador para o modelo e para a janela principal
* Mostrar janela principal
* (Save model, controller e para a janela principal em campos particulares aqui para se certificar de que eles são todos mantidos vivo)

6.Adicionar estilo (cores, tipos de letra) para separar um arquivo XAML em ResourceDictionary (usando o blend para este ou comprar pronta XAML tema/skin arquivo).

A vontade de querer escrever suas UIs em C #, em vez de XAML é realmente apenas uma manifestação de como você está confortável em XAML.

Para mim, é é um objetivo pessoal para escrever o mínimo de código-behind possível. Muito simplesmente, o código por trás é difícil de unidade-teste, mas pode (e geralmente o faz) incluir lógica que não fazer o teste. XAML é declarativa (como HTML) e não inclui qualquer lógica, então não há nada a unidade-teste. Eu mantenho o meu código de exibição em XAML e eu manter a minha lógica de exibição no meu ViewModel (MVVM), que é muito fácil de testar.

Uma vez que você se tornar mais confortável com XAML, mais você vai perceber os seus benefícios mais vista construção em código de procedimento ... Usando um padrão como MVVM, você leva um passo adiante, e perceber que code-behind é apenas em útil casos raros.

A coisa mais importante a ter em mente é que XAML é para a apresentação. Toda a sua apresentação deve ser no XAML. Se você tem lógica, você manter isso fora de seu XAML - em sua C #

.

Imagine que trocar seu arquivo XAML com um que parece completamente diferente - mas ainda usa os mesmos dados -. É aí que a divisão deve ser

Uma das coisas agradáveis ??sobre XAML é a separação da apresentação de uma lógica. Esta separação não é apenas teórica, mas também prática. I meu caso, a maioria dos meus UIs estão agora a ser tratado por um designer. Este designer usa mistura e não sabe C #, não tem interesse de learnning c #, e, francamente, não precisa. Este designer é um designer de verdade, um artista, que sabe como usar essas ferramentas para fazer as coisas parecerem realmente muito bom. Basicamente a minha phylosipy é isso, quanto mais eu uso XAML, menos trabalho que tenho a fazer sobre a interface do usuário, porque ele pode fazê-lo. Isso tem funcionado bem para nós. Eu costumo projetar meu controle para ser lookless, dar-lhes um olhar não folho básica, use o DataContext para ligar meu objeto (btw DataTriggers são uma ótima maneira de reduzir o código). Como resultado, eu, muitas vezes, checando meu código, voltar no dia seguinte, sincronizar-lo, ea interface do usuário vai olhar completamente diferente, mas tudo ainda trabalho !!!

Claro, levou pelo menos 1/2 anos para chegar lá, mas agora este modelo parece trabalho e nossa UI olhar pontapé A ##, a nossa aplicação ganha elogios, e eu faço pouco de trabalho no próprio e UI get para trabalhar em coisas mais frias. Para fazer uma longa história curta, acho que o trás código pode ser um pouco mais centrada no desenvolvedor e se esquece de um outro grupo inteiro que podem se beneficiar, trive, e fazer uma vida usando WPF, ou seja, os designers.

É claro, ainda há momentos em que é preciso uma devloper fazer XAML / WPF cantar e dançar, e em algum momento, precisamos educar os designers sobre a maneira certa de fazer as coisas, mas acho que o que vale o investement compensa muitos vezes mais em projetos de grande escala (talvez não tão em suma one0

XAML, MXML todas estas obras stuff enquanto você está desenvolvendo uma interface de usuário simples, com alguma complexidade média. Uma vez que seu UI recebe complexo e mais rico, as ligações automáticas de dados irá causar mais problemas do que os seus benefícios. O objetivo do XAML não é tornar a programação fácil, é a UI separado da lógica para que ferramentas de interface do usuário pode ser fácil ..

ligações sem dados, manipuladores de nenhum evento .. supor que você nunca vai ver o seu XAML novamente e escrever código ..

XAML é apresentação. ligação de dados não é apresentação. sua lógica de apresentação. colocar toda a lógica de apresentação em código por trás (ligação de dados e manipuladores). Desenvolvedores própria por trás do código, Designers possuir XAML. Se você é um desenvolvedor, e se você está tocando XAML, em seguida, passar essa parte para trás código.

podemos escrever aplicações WPF sem XAML também ..

Graças Kumar R vinoth (Tinha ido através suficiente usando dados Flex MXML de ligação)

Não é apenas sobre você, é também sobre sua equipe, alguns dos quais podem ser designers.

XAML e C # é realmente uma boa maneira de separar a lógica do projeto como já descrito.

Para um programador típico do modo de programação é realmente alterado usando WPF, assumindo que o programador vem de um C ++, VB, WinForms, ATL e fundo MFC, um fundo de foram a UI não era tão natural separado da lógica como com XAML e C #.

Para se acostumar com esta maneira de programar isso leva algum tempo, mas ficando mais e mais experience fica realmente eficaz.

Antes de começar, é realmente bom para aprender o padrão MVVM e para executar tutoriais para entender a força do teste padrão, e também para começar a entender seus benefícios.

WPF e C aplicações # com base em benefícios padrão MVVM:

1. User Experience e Usabilidade Separando a lógica de interface do usuário, faz com que seja mais natural para ter um trabalho de designer dedicado na UI design e animações. Desta forma, o programador pode concentrar-se na lógica por trás e a solução técnica enquanto o UI é projetado por alguém que conhece design. Isso tem sido um problema para muitas empresas de software, pelo menos na indústria que os programadores actualy são uma vez que está projetando a interface do usuário bem e que resultou em um monte de apoio, maintenance e em aplicações effecive.

Há uma maior probabilidade de que ele acaba com mais aplicações de fácil utilização por ter uma pessoa com Usabilidade fundo com foco no uso em vez da solução técnica. Não é um livro muito interessante abbout tais exemplos, User Interface Design for Programmers, por Joel Spolsky.

Ao usar o padrão MVVM para aplicação XAML há uma boa chance de que veremos mais usuários firendly aplicações.

2. Maintanence Manutenção, que é um custo muito dentro de desenvolvimento de software. Ele pode se sentir que o padrão MVVM é uma grande sobrecarga no início, mas ao mesmo tempo funções são adicionados e o mais complexo e avançado o aplicativo está recebendo o mais benéfico é. Você vai ver que ele é realmente fácil de maintaine tal pedido. Para uma visão geral você pode olhar para este vídeo:

3. Mix de competências desenhador dedicado e um programador dedicado trabalhar em equipe para alcançar um resultado melhor é uma boa forma de misturar competências. Em vez de apenas a contratação de organizações programadores precisa combinar as competências para fornecer os melhores resultados.

4. Oportunidade para os programadores interessados ??projeto Finalmente, é possível implementar aplicações de fantasia no ambiente do Windows. Se você é um programador que estão interessados ??em design do Microsoft Expression Blend realmente abre possibilidades para aprender e fantasia achive, aplicações úteis com um design agradável.

Não pode no entanto ser de risco, utilizando com XAML e C #, MVVM ou não, as grandes possibilidades e flexibilidade que ele fornece também pode ser uma desvantagem. Deixando o programador solta com este novo ambiente UI fácil, as aplicações podem acabar com um grande espectro de animações, cores, tudo o que este novo ambiente proporciona. Remebering como você adicionou controles de interface do usuário no C ++ e envrionment ATL.

Ainda assim, os benefícios são mais e eu espero que você obter alguma inspiração de usar XAML em vez de C # para a UI, quando se acostumar a ele que estou convencido de que você vai gostar.

Um link para um bom tuturial: Tutorial MVVM XAML C #

Eu originalmente veio do lado Web de desenvolvimento e estou aprendendo WPF / Silverlight no momento. Para mim, o modelo XAML faz muito mais sentido para mim do que WinForms já fiz. I tratar o XAML como se fosse HTML e os arquivos de cs apenas como um código.

Eu te amo código limpo, menos código que eu tenho, o aspirador é. Código pode ser escrito em milhões de formas, XAML é mais restritiva. XAML é bom em cortar código, quando for o caso, é claro. Se eu posso colocar algo em XAML, eu vou fazê-lo. Ferramentas pode ler XAML e fazer coisas com ele. Muito menos com o código. Ferramentas e frameworks de manipulação XAML vai evoluir e melhorar, fazer mais e melhor trabalho com XAML existente. Não posso dizer que sobre o código. Quanto mais evolui XAML, mais seremos capazes de definir declarativamente nossas aplicações.

Para mim, usando XAML é como usar LINQ. Se eu posso escrever uma declaração de uma linha que é fácil de ler e deixar um quadro decidir a melhor forma de implementar o que eu quero, me sinto bem. I definitivamente tentar, tanto quanto eu puder, utilize declarações de que eu quero em vez de codificar como eu quero que ele seja feito. F # é outro bom exemplo deste paradigma.

Toda a lógica deve estar em código, independentemente do que você programando linguagem que você usa em programação de computadores. XAML não deve nunca substituir que, mesmo em ControlTemplate embora seja bom, mas é muito mais fácil de teste de unidade e depurar o código.

Parece há respostas mencionou um ponto importante ainda: https://msdn.microsoft.com/en-us /library/windows/apps/xaml/hh465340.aspx

XAML é apenas o código de procedimento (só mais fácil) 

<Grid x:Name="ContentPanel" Margin="12,0,12,0">
    <Button Height="72" Width="160" Content="Click Me" />
</Grid>

"O seguinte mostra como este XAML poderia ser parcialmente substituídas por código escrito em C # ou Visual Basic." 

// Initialize the button
Button myButton = new Button();
// Set its properties
myButton.Width = 160;
myButton.Height = 72;
myButton.Content = "Click Me";
// Attach it to the visual tree, specifically as a child of
// a Grid object (named 'ContentPanel') that already exists. In other words, position
// the button in the UI.
ContentPanel.Children.Add(myButton);

Se você trabalhou com Windows Forms por exemplo, você provavelmente se lembra o designer Windows Forms gera um arquivo .Designer.cs contendo código semelhante ao exemplo a partir do link acima. Esse tipo de código declarativa é muito melhor representados em XAML de C #.

Para qualquer aplicação não-brinquedo que você deve sempre preferir XAML para definir UI e conectá-lo à lógica de uma maneira MVVM.

Algumas coisas são mais fáceis de manter ou de depuração no código.

Para não mencionar que você vai ser capaz de fazer mais em XAML2009 que tem de ser feito em código por trás agora.

Unfortantly BAML não vai apoiar plenamente xaml 2009 em VS 2010 período de tempo para que você não pode xaml compilação em 2010 período de tempo. E terá de esperar por uma versão posterior do blend para fazer o ciclo de projeto dev completo. (Até 3)

Douglas

XAML pode ser visto como sendo semelhante a uma combinação de XHTML e CSS ou XML e XSL, que são utilizados para a estrutura e design. Qualquer forma de lógica deve estar em C #. Esta estrutura forma e design são separados da lógica. O seu código deve ser limpo também usando esta abordagem. Outra coisa positiva é que as tarefas podem ser mais fácil de separar entre designers e programadores.

Mais uma coisa ... esta é a definição de XAML da MSDN:

Extensible Application Markup Language (XAML) é uma linguagem de marcação para a programação de aplicação declarativa. Windows Presentation Foundation (WPF) implementa um carregador de Extensible Application Markup Language (XAML) e fornece Extensible Application Markup Language suporte ao idioma (XAML) para o Windows Presentation Foundation tipos (WPF) de tal forma que você pode criar a maioria de seu UI aplicação em Extensible Application Markup Language (XAML) marcação. Além disso, o SDK inclui uma ferramenta de edição Extensible Application Markup Language (XAML) chamado XAMLPad. Você pode usar essa ferramenta para experimentar com Extensible Application Markup Language (XAML) em tempo real.

Link para citar.

Programação WPF em C # com um estilo fluente ajuda a manter o tamanho do código e complexidade baixo. Consulte esta resposta para um exemplo de como usar um estilo fluente com WPF.

Licenciado em: CC-BY-SA com atribuição
Não afiliado a StackOverflow
scroll top