Preparando para o futuro um grande aplicativo de UI - MFC com pacote de recursos de 2008 ou C# e Winforms?

Question

Minha empresa desenvolveu um produto de longa data usando MFC em Visual C++ como padrão de fato para desenvolvimento de UI.Nossa base de código contém MUITO código legado/arcaico que deve ser mantido operacional.Parte desse código é mais antigo que eu (originalmente escrito no final dos anos 70) e alguns membros de nossa equipe ainda usam o Visual Studio 6.

No entanto, felizmente, chegou-se internamente à conclusão de que o nosso produto parece um tanto antiquado em comparação com o dos nossos concorrentes e que algo precisa ser feito.

Atualmente estou trabalhando em uma nova área da UI que é bastante separada do resto do produto.Portanto, tive a oportunidade de experimentar 'novas' pilhas de tecnologia como uma espécie de campo de provas antes do longo processo de mudança do restante da IU começar.

Tenho usado C# com Windows Forms e o framework .net há algum tempo em meu tempo livre e gosto disso, mas estou um pouco preocupado com as dores de cabeça causadas pela interoperabilidade.Embora esse ramo específico da UI não exija muita interoperabilidade com a base de código C++ herdada, posso prever que isso se tornará um problema no futuro.

A alternativa é apenas continuar com o MFC, mas tente aproveitar as vantagens do novo pacote de recursos fornecido com o VS2008.Acho que essa é a opção mais fácil, mas me preocupo com a longevidade e em não aproveitar a bondade que é o .net...

Então, o que eu escolho?Somos uma equipe pequena, então minha recomendação provavelmente será aceita como uma direção futura para nosso desenvolvimento - quero acertar.

O MFC está morto?C#/Winforms é o caminho a seguir?Há mais alguma coisa que estou perdendo totalmente?Ajuda muito apreciada!

Answer 1

Sou desenvolvedor de um aplicativo que possui muitos códigos MFC legados e temos as mesmas preocupações.Um grande impulsionador da nossa estratégia foi eliminar o máximo de risco e incerteza possível, o que significava evitar a Grande Reescrita.Como todos sabemos, o TBR falha na maioria das vezes.Portanto, escolhemos uma abordagem incremental que nos permite preservar módulos que não serão alterados na versão atual, escrevendo novos recursos gerenciados e portando recursos que estão sendo aprimorados para serem gerenciados.

Você pode fazer isso de várias maneiras:

1. Hospede conteúdo WPF em suas visualizações MFC (consulte aqui)

2. Para aplicativos MFC MDI, crie uma nova estrutura WinForms e hospede suas visualizações MFC MDI (consulte aqui)

3. Hospedar controles de usuário do WinForms em caixas de diálogo e visualizações do MFC (consulte aqui)

O problema com a adoção do WPF (opção 1) é que será necessário reescrever toda a sua UI de uma só vez, caso contrário, parecerá bastante esquizofrênico.

A segunda abordagem parece viável, mas muito complicada.

A terceira abordagem é a que selecionamos e tem funcionado muito bem.Ele permite que você atualize seletivamente áreas do seu aplicativo, mantendo a consistência geral e sem tocar em coisas que não estão quebradas.

O Visual C++ 2008 Feature Pack parece interessante, mas ainda não brinquei com ele.Parece que isso pode ajudar com seu problema de aparência desatualizada.Se a "faixa de opções" for muito chocante para seus usuários, você poderá consultar fornecedores terceirizados de controle MFC e/ou WinForms.

Minha recomendação geral é que a interoperabilidade + mudança incremental é definitivamente preferível a mudanças radicais.

---

Depois de ler o seu acompanhamento, posso confirmar definitivamente que os ganhos de produtividade do framework superam amplamente o investimento em aprendê-lo.Ninguém em nossa equipe havia usado C# no início deste esforço e agora todos nós o preferimos.

Answer 2

Dependendo do aplicativo e da disposição de seus clientes em instalar o .NET (nem todos o fazem), eu definitivamente mudaria para WinForms ou WPF.A interoperabilidade com código C++ é extremamente simplificada pela refatoração de código não UI em bibliotecas de classes usando C++/CLI (como você observou em sua seleção de tags).

O único problema com o WPF é que pode ser difícil manter a aparência atual.A mudança para o WinForms pode ser feita mantendo a aparência atual da sua GUI.O WPF usa um modelo tão diferente que tentar manter o layout atual provavelmente seria inútil e definitivamente não estaria no espírito do WPF.Aparentemente, o WPF também apresenta baixo desempenho em máquinas anteriores ao Vista quando mais de um processo WPF está em execução.

Minha sugestão é descobrir o que seus clientes estão usando.Se a maioria mudou para o Vista e sua equipe está preparada para trabalhar muito com a GUI, eu diria para pular o WinForms e mudar para o WPF.Caso contrário, definitivamente dê uma olhada séria no WinForms.Em ambos os casos, uma biblioteca de classes em C++/CLI é a resposta para suas preocupações de interoperabilidade.

Answer 3

Você não fornece muitos detalhes sobre o que seu código legado faz ou como ele está estruturado.Se você tiver determinados critérios de desempenho, talvez queira manter parte de sua base de código em C++.Você terá mais facilidade em interoperar com seu código antigo se ele for exposto da maneira correta - você pode chamar a base de código existente do C# hoje?Talvez valha a pena pensar em um projeto para acertar essa estrutura.

No que diz respeito ao WPF, você poderia argumentar que o WinForms pode ser mais apropriado.Mudar para o WinForms é um grande passo para você e sua equipe.Talvez eles se sintam mais confortáveis ​​com a mudança para o WinForms?Está melhor documentado, tem mais experiência no mercado e é útil se você ainda precisar oferecer suporte a clientes Windows 2000.

Você pode estar interessado em Estendendo aplicativos MFC com o .NET Framework

Outra coisa a considerar é C++/CLI, mas não tenho experiência com isso.

Answer 4

Obrigado a todos pelas vossas respostas, é reconfortante ver que geralmente o consenso segue a minha linha de pensamento.Estou na feliz situação de que nosso software também roda em nosso próprio hardware personalizado (para a indústria de transmissão) - então a escolha do sistema operacional é realmente nossa e é imposta aos nossos clientes.Atualmente estamos rodando o XP/2000, mas vejo um desejo de migrar para o Vista em breve.

No entanto, também precisamos manter um controle muito preciso sobre o desempenho da GPU, o que eu acho que exclui automaticamente o WPF e a aceleração de hardware.Eu deveria ter mencionado esse ponto em minha postagem original - desculpe.Talvez seja possível usar duas GPUs...mas isso é outra questão...

A equipe não tem nenhuma experiência significativa em C# e eu não sou especialista, mas acho que os benefícios gerais de longo prazo de um ambiente gerenciado provavelmente superam o tempo que levará para se atualizar.

Parece que Winforms e C# têm isso por enquanto.

Answer 5

Se você pretendesse mudar para C# e, portanto, .NET, eu consideraria o Windows Presentation Foundation em vez do WinForms.WPF é o futuro dos clientes inteligentes em .NET, e as habilidades que você adquirir poderão ser reutilizadas se quiser criar aplicativos Silverlight hospedados em navegador.

Answer 6

Concordo com o sentimento do WPF.A UI baseada em Tag/XML parece ser um pouco mais portátil que o WinForms.

Eu acho que você também deve considerar sua equipe, se não houver muitas habilidades atuais em C#, então isso é um fator, mas daqui para frente o mercado para desenvolvedores MFC está diminuindo e C# está crescendo.

Talvez algum tipo de abordagem fragmentada fosse possível?Estive envolvido bastante com a recodificação de aplicativos legados para C#, e isso sempre leva muito mais tempo do que você estimaria, especialmente se você estiver mantendo algum código legado ou se sua equipe não estiver tão familiarizada com C#.