Pergunta

Para sua informação - sou um mainframer que mudou para o mundo .NET há alguns anos e tem muito que aprender.

Estamos pensando em reescrever um aplicativo Visual FoxPro em .Net (provavelmente VB).Este projeto está projetado para 4 a 6 anos.

Estamos nos estágios iniciais do projeto preliminar agora.Estou vendo MUITAS informações da Microsoft sobre o VS 2010.Há algo de errado com 2005/2008 que nos deva preocupar?Ou este SOP é para a MS começar a promover produtos futuros tão cedo?Vale a pena esperar 2010 para iniciar qualquer codificação?De qualquer forma, o design funcional provavelmente não estará concluído até o final do ano (2009) e sempre podemos fazer maquetes no VS-2005.

Em segundo lugar, FoxPro e VB6 estão no mesmo barco;sem suporte, mas vivo por enquanto.Mudar para .NET é inteligente?VB?C#?Chegará um momento em que a MS decidirá que a mudança para o VS 20xx exigirá outra reescrita completa do código antigo (VB6)?Ou eles poderiam eliminar o VB.net ou o C#.net para a próxima novidade 'ótima' (foxpro)?Ou que tal a vida útil do framework .NET?Também é limitado até que algo mais apareça?

Temos um aplicativo muito grande com anos de band-aids, atualizações e mudanças na lei que já será uma PIA para converter.Queremos uma nova plataforma que seja estável durante décadas, com migrações fáceis para cima.Existe qualquer código de desenvolvimento que ocorrerá daqui a 50 anos?100?

A lógica central do aplicativo não mudou muito desde que eles usaram papel e caneta.É difícil justificar agora uma reescrita plurianual se esta precisar ser feita a cada 10-20 anos.O aplicativo FoxPro começou a ser desenvolvido em 1991, foi lançado em 1999 e agora deve ser reescrito em outro idioma.

Mainframes são fáceis em comparação com a fluidez dos Win Apps.

Aqui estão algumas especificações de alto nível.

  • É para um escritório do governo.
  • Ele contém dados altamente confidenciais.
  • Baseado na Web não é uma opção.
  • Será um aplicativo apenas para MS Windows.
  • Iremos migrar das tabelas FoxPro para, provavelmente, SQL Server 2005/8/10 (o que for atual)

Eu sei que aqueles com bolas de cristal funcionais não responderão, mas qual é o problema? sentir da comunidade quanto à probabilidade de uma linguagem de programação se estabelecer e ficar disponível/estável a longo prazo?

Obrigado por suas opiniões sobre isso, eu as aprecio.

Foi útil?

Solução

onde posso conseguir um desses empregos públicos confortáveis????

de qualquer forma, sim, é SOP da Microsoft anunciar e demonstrar sistemas operacionais, ferramentas de desenvolvimento, etc. antecipadamente, isso não significa que haja algo errado com as ferramentas atuais.Desde o VS2003, sempre foi extremamente fácil migrar projetos para novas versões do ambiente de desenvolvimento, se alguém decidir fazê-lo; portanto, basta começar com qualquer versão do VS atual quando estiver pronto para escrever o código.

O .NET mudará enquanto você escreve isso, mas eles têm sido muito bons em manter a compatibilidade com versões anteriores da estrutura, portanto, também não há problema.

Eu recomendaria C# em vez de VB.Net se você for reescrever de qualquer maneira.VB.Net era uma espécie de linguagem band-aid para colocar programadores VB em .Net e às vezes é útil para compatibilidade, mas não sei por que você deseja iniciar um novo desenvolvimento com ela.

Outras dicas

O Windows realmente não é uma plataforma adequada para aplicativos de vida longa, como você está descrevendo. É por isso que os fornecedores de mainframe/grande ferro, embora mais fracos do que costumavam ser, ainda estão por aí.

Well obviously nobody can tell exactly what's going to happen to all the latest/greatest stuff in the future. If you were a Mac OS programmer in the '80s and '90s you'd probably be a bit annoyed too if not quite in the same boat as VB6 programmers.

.NET and VB.NET/C# are a viable proposition in the long term. They are in a different situation to stuff like classic VB and FoxPro in that they run in a virtual machine that has use to lots of different languages. As such, even if a new more popular language comes along that targets .NET, your old code will still run.

When you say you want a desktop application rather than something web-based, that is a concern because Windows Forms (the traditional VB-like user interface framework) is not receiving much attention from Microsoft already. It's not going to go away like I said, but there's not going to be much future improvement to it. If you are working on a massive never-changing app like you say, then this might not be a problem for you.

The alternative .NET user interface framework is WPF, which is the latest-greatest. There are questions over the long-term viability of this due to its extraordinary resource useage. So far there is only one significant desktop app that uses it (Microsoft's own WPF design tool Expression Blend) and to try and convince people WPF really is viable they have committed to using WPF in Visual Studio 2010 for parts of the user interface like the editor. Even so, I'd find it hard to recommend WPF for the application you describe - it's just too risky.

As to your question about Visual Studio versions, VS2005 wasn't very good (rushed out the door eary with some serious performance issues). VS2008 however is a fine release and you would be well advised to start your project with that - there is no guarantee that 2010 will be better (or even as good due to the WPF factor). Teams tend to use Visual Studio versions for a long time (my employer is still using 2003 for some work!) and all versions peacefully co-exist on a single machine.

And yes, Microsoft does tend to talk about dev tools well in advance of when they are available. Apparently the "osbourne effect" doesn't apply to developer tools :)

I've heart from my partners- there is an engine (team from Ukraine has it) to convert VFP application into the dot net, that will work with an existing DBF files. So - instead rewriting - you just run the convertor (one time deal) and instead FoxPro apps, you'll have dot net. If you’d like more detail please let me know

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