WPF vs. WinForms - uma perspectiva do programador Delphi?

37

Eu li a maioria dos tópicos principais no WPF vs. WinForms e me vejo preso à ambivalência infeliz em que você pode cair ao decidir entre a tecnologia anterior testada e comprovada (WinForms) e sua sucessora (WPF).

Eu sou um veterano programador Delphi de muitos anos que finalmente está dando o salto para C #. Meus colegas programadores Delphi por aí vão entender que estou animado em saber que Anders Hejlsberg, da fama de Delphi, foi o arquiteto por trás do C #. Eu tenho um strong vício em componentes customizados VCL do Delphi, especialmente aqueles envolvidos na criação de assistentes e componentes de várias etapas que atuam como um contêiner para componentes filhos.

Com esse histórico, espero que aqueles que mudaram do Delphi para o C # possam me ajudar com minha decisão do WinForms vs. WPF para escrever meus aplicativos iniciais. Note, eu sou muito impaciente quando codifico e coisas como auto-completar completo e suporte a depurador adequado pode fazer ou quebrar um projeto para mim, incluindo ser capaz de encontrar informações prontamente disponíveis sobre recursos e chamadas API e mais ainda, soluções alternativas para bugs .

Os tópicos e comentários do SO no intervalo de datas do início de 2009 me causam grande preocupação com o WPF quando se trata de possíveis frustrações que podem prejudicar minha codificação de desenvolvimento do C # UI. Por outro lado, gastar uma quantidade excessiva de tempo aprendendo uma tecnologia de API que é, mesmo que não seja abandonada, em breve a ser substituída (WinForms), é igualmente preocupante e eu acho o suporte da GPU no WPF tentador.

Daí minha ambivalência. Como ainda não aprendi nenhuma das técnicas, tenho uma rara oportunidade de começar de novo e não ter de enfrentar a grande curva de "desaprendizagem" que vi pessoas mencionarem em vários segmentos quando um programador do WinForms faz a migração para o WPF. Por outro lado, se usar o WPF será frustrante demais ou terá outras conseqüências negativas importantes para um desenvolvedor RAD impaciente como eu, então vou continuar com o WinForms até que o WPF atinja o mesmo nível de suporte e facilidade de uso. Para dar a você um exemplo concreto de minha psicologia como programador, usei o VB e, subsequentemente, o Delphi para evitar completamente a dor real da codificação com o MFC, uma biblioteca de interface do Windows que muitos desenvolvedores sofriam durante o desenvolvimento dos primeiros aplicativos do Windows. Eu nunca me arrependi da minha sorte em evitar o MFC.

Também seria reconfortante saber se Anders Hejlsberg tinha uma mão na arquitetura do WPF e / ou WinForms, e se há alguma disparidade na visão criativa e facilidade de uso incorporada em qualquer base de código. Finalmente, para os programadores do Delphi novamente, deixe-me saber quanto "IDE schock" eu estou usando ao usar o WPF em vez do WinForms, especialmente quando se trata de suporte ao depurador. Quaisquer comentários sobre o mercado de trabalho atualizados para 2011 também serão apreciados.

    
por Robert Oschler 01.03.2011 / 19:00
fonte

10 respostas

19

Se você tem um fundo Delphi, ficará desapontado com o WinForms. Você tentará fazer coisas que fossem fáceis no VCL, apenas para descobrir que elas são dolorosamente difíceis, ou mesmo impossíveis. O WPF será muito menos confinado.

Por exemplo, aqui estão apenas algumas das limitações do WinForms que encontramos:

  • O WinForms não tem nada comparado ao TAction, portanto, se você está acostumado a codificar com ações, compartilhando o mesmo texto e ícone entre um item de menu e um botão da barra de ferramentas e um menu do botão direito, centralizando sua lógica de habilitação e atualizando o estado habilitado em segundo plano com o OnUpdate ... você vai odiar o WinForms, onde você tem que fazer tudo o que é difícil e propenso a erros.
  • O antigo MainMenu do WinForms (.NET 1.0 vintage) não suporta imagens ao lado de itens de menu, e o novo (introduzido no .NET 2.0) MenuStrip é cheio de bugs que a Microsoft se recusa a corrigir (porque as correções podem quebrar a compatibilidade com versões anteriores).
  • Muitos controles, por exemplo o TreeView, infelizmente, são sub-caracterizados em comparação com os seus homólogos VCL (dolorosamente lento, sem dono draw, muitas opções de personalização em falta, etc.)
  • Não há nada parecido com a comunidade vibrante de desenvolvedores de controle de terceiros com os quais você está acostumado no Delphi. Existem bibliotecas de controle de qualidade por aí, mas você paga por elas - ofertas gratuitas como o VirtualTreeView simplesmente não estão disponíveis no WinForms.

O WPF é um pouco mais básico em alguns aspectos do que o WinForms, mas é imensamente mais extensível.

  • Você quer algo como TAction? O WPF tem o ICommand, que é tão rico quanto você está acostumado (mas certifique-se de ler o MVVM do Josh Smith artigo - normalmente você precisa ativar / desativar seus comandos manualmente quando o estado muda, mas a versão dele dispara automaticamente o código de ativação em segundo plano, como você está acostumado com o OnUpdate).
  • Você quer imagens nos menus? Isso é construído em (e nem de longe tão buggy como no WinForms).
  • O WinForms deixa o proprietário desenhar em alguns controles importantes, mas se você estiver usando o WPF, não precisa desenhar o proprietário - se quiser que os nós do TreeView tenham texto em preto seguido por um número azul entre parênteses, basta colocá-lo em seu DataTemplate e ele funciona, não é necessário um código feio para desenhar o proprietário.
  • Você deseja controles de terceiros? Em muitos casos, você não precisa deles, porque você pode estender o que há de alguma forma WinForms e, sim, os desenvolvedores de VCL só podem sonhar.

O WPF tem uma curva de aprendizagem muito íngreme, mas se você pegar um bom livro (por exemplo, " WPF 4 Solto "), ajudará você a superar o pior - e você ficará feliz em trabalhar com um framework que não vai prender você do jeito que o WinForms vai fazer.

    
por 01.03.2011 / 20:18
fonte
13

Geralmente fico muito surpreso com as pessoas dizendo que não tiveram uma boa experiência com o WPF. Eu sou um desenvolvedor que passou de C ++ / MFC para C # / WinForms para C # / WPF. A transição do WinForms para o WPF não foi fácil, porque aprender XAML não é muito fácil, mas quando você se apega a ele, é uma tecnologia incrível. Eu, por exemplo, não posso voltar para o WinForms. O WPF é simplesmente fantástico.

A outra coisa que me incomoda é como as pessoas normalmente associam o WPF apenas com a interface do usuário. Na verdade, é 100 vezes melhor do que o WinForms na minha opinião, na facilidade de design da interface do usuário, mas há muitas outras razões que você vai adorar usar o WPF:

  1. UI, claro.
  2. Ligações. Apenas pura magia. O recurso mais poderoso após a interface do usuário. Aplicativos LOB se beneficiam disso mais.
  3. Comandos.
  4. Separação de preocupações. Designers trabalham em design, programadores programadores.
  5. Propriedades anexadas. Você pode estender a funcionalidade de controles de terceiros sem o código fonte (embora esse ponto possa fazer parte do primeiro ponto).
  6. Transição fácil para o Silverlight (Web e WP7)

Você pode não concordar comigo sobre o último ponto como uma razão para você aprender o WPF, mas se você me perguntar, é um dos maiores. Você aprende WPF, você pode facilmente fazer a transição para o Silverlight. O Silverlight está crescendo e é também uma tecnologia incrível.

E o maior motivo é, é o futuro. Ele pode ser mesclado com o Silverlight, mas as habilidades permanecerão as mesmas.

Então, eu aconselho você a seguir o caminho do WPF.

    
por 01.03.2011 / 19:35
fonte
5

Claramente o WPF é o caminho a percorrer no futuro. Dominar é difícil, mas a plataforma é muito bem arquitetada e flexível.

Algumas dicas:

  • Comece fácil: não tente implementar seu primeiro projeto usando apenas MVVM ou animações sofisticadas. Comece de maneira simples com janelas, botões e listas.
  • Aproveite o DataBinding.
  • Compre o livro WPF Unleashed de Adam Nathan.
por 01.03.2011 / 19:39
fonte
4

Devo primeiro notar que sou principalmente um desenvolvedor do asp.net, embora eu já tenha usado bastante o winform. A mudança para o WPF não é tão grande como você está fazendo (imo) depois de uma semana ou mais (40 horas), a maioria era segunda natureza novamente.

De qualquer forma, eu acredito que Anders Hejlsberg é um dos arquitetos por trás da WPF, pelo menos de acordo com os editores deste livro - >

Como um dos arquitetos por trás da WPF, Chris Anderson explica habilmente não apenas o 'como', mas também o 'porquê'. Este livro é um excelente recurso para qualquer pessoa que queira entender os princípios de design e melhores práticas. do WPF. ” –Anders Hejlsberg, bolsista técnico da Microsoft Corporation

link

    
por 01.03.2011 / 19:09
fonte
2

O WinForms é quase idêntico ao desenvolvimento do Delphi. E, claro, há uma razão para isso. Assim como o modelo de objeto Delphi / Object Pascal influenciou strongmente o C #, o sistema de formulários influenciou o WinForms.

O WPF parece ser o rumo que as coisas estão tomando; Foi dito que a (linda!) UI do VS2010 é baseada no WPF, ao contrário das gerações anteriores que foram construídas no WinForms.

Se você quiser ficar na sua zona de conforto, vá com winforms. Se você quer se envolver com as últimas novidades & maior, mergulhe no WPF.

    
por 01.03.2011 / 19:17
fonte
2

Eu não sou um programador Delphi, mas sim eu trabalhei tanto no WinForm (strongmente) quanto no WPF (menos que moderado). Eu concordo com você até certo ponto no nível de frustração para alguém que estaria fazendo uma mudança do WinForm para o WPF, já que estou nessa situação, mas apenas até me acostumar com isso. Aprenda e veja como é maravilhoso e flexível com o WPF em comparação com o WinForm. Tem uma pesada curva de aprendizado, pelo menos para alguém que vem do fundo Delphi, e não do Winform. Para você, definitivamente vale a pena ir em direção ao WPF em vez do WinForm, e vale a pena o tempo.

Você pode pesquisar os links abaixo para começar:

por 01.03.2011 / 19:25
fonte
1

Eu tinha feito algum trabalho no Windows Forms (principalmente em Pocket PCs), além de algum outro ambiente não -.NET que usava os mesmos princípios. Quando me mudei para a WPF, há cerca de três anos, durante os primeiros meses, fiquei xingando. Eventualmente apenas "clicado" e eu não olhei para trás - na verdade eu ficaria chateado se o meu próximo projeto exigisse que eu voltasse para o Windows Forms.

A última vez que o Windows Forms foi atualizado foi em 2005 (VS 2005.) Ele ainda está lá, mas não está mais sendo aprimorado pela Microsoft. WPF é o novo garoto no bloco para aplicativos de desktop, então se você for migrar para a plataforma .NET usando ferramentas MS, então eu diria que é a aposta segura. Algumas pessoas usam o Silverlight como uma solução de desktop, mas quando olhei para ele como uma possibilidade, descobri que ele tinha muitas limitações (o que pode fazer sentido em um contexto da Web, mas não tanto na área de trabalho).

Linha de fundo: Há uma curva de aprendizado íngreme e ainda estou aprendendo. Mas valeu a pena. É muito divertido.

    
por 01.03.2011 / 19:40
fonte
1

Se você for escrever novos aplicativos a partir do zero, usar o WinForms seria um erro. É basicamente morto de uma perspectiva de investimento. A Microsoft manterá isso por um longo tempo, mas você não terá nenhum novo recurso ou novo suporte, etc. O WPF é a direção clara para aplicativos de desktop para o futuro na plataforma MS.

De uma perspectiva de carreira, você também está muito melhor conhecendo o WPF vs. WinForms. Pelas mesmas razões acima. Além disso, você terá uma boa vantagem no aprendizado do Silverlight. Há uma tonelada de sobreposição entre essas duas plataformas.

E, finalmente, o WPF é simplesmente mais divertido. E mais poderoso.

A curva de aprendizado é mais acentuada, eu lhe dou isso. Mas é mais recompensador no final.

    
por 01.03.2011 / 20:09
fonte
0

Uma consideração adicional que deve ser mencionada é que não há nenhum plano para o suporte do WPF em mono . Eu percebo que você não demonstrou nenhum interesse em suporte (mono) multiplataforma, mas pode haver uma oportunidade para isso em seu futuro (se você for com o WinForms). Presumivelmente, o suporte para WPF em mono (ou similar) virá.

edit: Como o link que eu forneci apontou, e o comentário de Gulshan foi destacado, Moonlight é um esforço de código aberto liderado pela equipe mono fornecer suporte Silverlight entre plataformas .

    
por 02.03.2011 / 03:28
fonte
-1

Eu estava animada quando ouvi falar do WPF, a ideia parecia ótima, e tudo que eu vi foi maravilhoso. No entanto, quando eu comecei a usá-lo no Visual Studio 2008 (reconhecidamente, um beta), achei frustrante e peculiar trabalhar com o designer / IDE.

Postei uma pequena informação no meu blog na época: link
link

Eu não tentei isso em 2010, apesar de eu ter falado com algumas pessoas que têm, e parece que ainda é um pouco complicado / chato lidar com isso.

Eu acho que seu aplicativo, sem dúvida, parecerá / se sentirá melhor no WPF, mas também acho que levará mais tempo para você construir e você vai bater muito com a cabeça ao longo do caminho.

    
por 01.03.2011 / 19:17
fonte