ASP clássico para ASP.net ou ASP.net MVC

Temos um aplicativo da Web desenvolvido em ASP clássico e evoluiu ao longo de 5 anos para sua forma atual, com centenas de páginas, banco de dados enorme e mais de 10000 usuários ativos, passando pelo menos mais de 10 páginas por dia.

Agora, queríamos atualizá-lo para a versão mais recente do .net. Inicialmente, pensamos em reescrever o aplicativo inteiro, mas depois de analisar o cenário, descobrimos que essa não é uma opção viável e também não sugerida por muitos especialistas. Ainda não decidimos como fazê-lo de outra forma, mas pensamos em como conseguir a reescrita nos rostos.

Opção 1: Pensamos em identificar os módulos principais neste aplicativo e reescrevê-los um por um, separando o aplicativo em diferentes camadas, como banco de dados (existente), lógica de negócios e visualização. Dessa forma, os módulos recém-desenvolvidos serão adicionados ao sistema existente e novas páginas substituirão as páginas antigas desse módulo em particular. Ao mesmo tempo, podemos testar as novas camadas ao lado do sistema antigo e liberá-las quando nos sentirmos confiantes. Também pensamos em desenvolver um tipo de estrutura de API para lógica de negócios e isso será acessado por visualização como um aplicativo externo.

Opção 2: No momento, fizemos um módulo simples e o usamos na página ASP clássica por meio de um IFrame, embora tenha sido bastante problemático enviar dados entre o ASP clássico e a nova página no IFrame.

Isso está apenas no estágio de planejamento de como devemos obter a reescrita de todo o aplicativo sem perturbar a base de usuários.

Desejo obter pontos de vista, opiniões e sugestões de outros programadores sobre como devemos abordar nesse cenário? se alguém já enfrentou esse tipo de cenário, compartilhe sua opinião também.

Também gostaria de saber que o uso do ASP.net MVC vai me ajudar nisso?

ATUALIZAÇÃO : obrigado pelas duas respostas para colocar suas opiniões. Gostaria de obter mais entradas sobre as opções especificadas acima na migração do aplicativo do asp clássico para o asp.net ou o asp.net mvc. Seria uma grande ajuda para mim, se todos vocês puderem através de seus pontos de vista, pontos de vista e opiniões sobre a parte da migração, em vez de escolher o asp.net ou o asp.net mvc.

Deixe-me começar dizendo: "Sinto sua dor, brutha". Eu passei por isso há 3 anos e gostaria que o MVC tivesse amadurecido naquele momento porque a solução WebForms que eu projetei bastante se assemelha ao modelo MVC sem realmente ter as bibliotecas da Microsoft construídas para mim (é claro, havia vários gritantes "Why the hell" eu fiz isso "diferenças).

Também acabei usando iFrames para gerenciar as diferenças de conteúdo usando .Net como aplicativo pai e asp clássico como escravo. Eu desenvolvi a arquitetura do framework em .Net e implementei isso. As páginas asp clássicas foram então "selecionadas" de peças de apresentação desnecessárias (inclui e outros enfeites) e carregadas nos iFrames. Os dados foram passados ​​pelo URL usando uma criptografia personalizada. Para garantir que a autenticação não pudesse ser falsificada facilmente e que a página fosse acessada quebrando a string de consulta, também empregamos manipuladores curinga no IIS que forçaram o .Net a se autenticar antes de analisar as páginas asp clássicas.

Dado isso, minha recomendação seria ir imediatamente ao MVC.

1. O MVC dará acesso ao roteamento no nível global.asax. Com a manipulação inteligente de um controlador, você pode desenvolver seus modelos de maneira adequada e ter um controlador comum que lide com todas as solicitações clássicas de asp, conforme necessário.
2. O MVC tornará muito simples a adição de um projeto de teste e permitirá refatorar partes de aplicativos individuais com base na nova estrutura do modelo enquanto fornece cobertura de teste adequada para garantir que você esteja fazendo tudo certo. O valor disso é absolutamente incalculável, porque em qualquer código de refatoração a cobertura é uma grande preocupação.
3. O MVC segue uma abordagem mais baseada em scripts da apresentação do que o WebForms. O WebForms tenta misturar tudo como se fosse algum tipo de aplicativo com estado (o que não é), e isso pode ser um choque cultural para as pessoas acostumadas ao asp clássico. Não me interpretem mal, seus desenvolvedores sofrerão um choque cultural, não importa para onde você for, mas se você conseguir tirar um pouco desse choque da camada de apresentação, poderá obter maior sucesso.

Gosto de WebForms e MVC (apesar de admitir que com a introdução do Razor estou me tornando um pouco tendencioso em relação ao MVC). Ambos têm o seu lugar, e acho que um aplicativo como o que você descreve pode ser ideal para uma implementação de MVC, principalmente devido à natureza "escalonada" que você precisará adotar ao implantar peças de aplicativos refatoradas.

Seja como for, acho que você precisa ter certeza de que o aplicativo .Net é sempre o aplicativo pai quando se trata de autenticação / autorização / roteamento / etc. Um colega meu implementou sua migração em um aplicativo semelhante, com asp clássico como pai, e ele teve um grande número de problemas quando finalmente integrou tudo.

Adotar o ASP.NET MVC não facilitará necessariamente a transição e pode, de fato, dificultar a transição. No entanto, quando você já optou por realizar esse grande empreendimento, por que não reservar um tempo para avançar e ir para a plataforma que melhor se adapta aos seus planos?

A migração para o ASP.NET (sem MVC) será "mais fácil", no sentido de que geralmente você pode executar portas diretas da lógica existente sem precisar fazer muita refatoração, desde que não esteja fazendo muitas coisas exóticas com ASP clássico. Os resultados serão satisfatórios e relativamente familiares para as pessoas que já estão familiarizadas com o aplicativo. Você obterá benefícios no sentido de que todos os aplicativos transportados do ASP clássico para o ASP.NET recebem benefícios .

Migrar para o ASP.NET MVC será mais trabalhoso. Provavelmente, será necessário re-projetar seu modelo de aplicativo para se ajustar ao padrão MVC . Geralmente, isso é uma coisa boa (tm), porque incentiva bons comportamentos, como a separação de preocupações. O aplicativo resultante provavelmente não se parece muito com o que você tem, exceto as peças lógicas principais. Você também terá outras vantagens . Será uma grande mudança de cultura e será necessária alguma (re) educação da equipe de desenvolvimento para entender "como escrever MVC" corretamente.

É importante ressaltar que a Microsoft não está abandonando o WebForms de acordo com o ScottGu (a partir de um ano atrás), mas não acho difícil afirmar que, se / quando decidirem eliminar uma dessas duas tecnologias, será WebForms.

Concordo plenamente que o ASP.NET MVC é o caminho a percorrer. Não será fácil, não será mais fácil, mas certamente é muito mais prova de futuro do que os WebForms. Embora o WebForms certamente não tenha sido abandonado, os aplicativos que os utilizam ficam cada vez mais difíceis de manter à medida que os aplicativos se tornam cada vez maiores.

Eu desencorajo fortemente o uso de WebForms em aplicativos "grandes".

Eu gosto da Opção 1) (com MVC) muito melhor que a Opção 2), pois permite que você evolua o aplicativo de forma incremental, sem precisar acoplar os dois aplicativos tanto quanto faria com a abordagem iFrames.

Eu tive alguma experiência com a migração de um aplicativo antigo para o ASP.Net e um dos desafios foi compartilhar alguns dos recursos, como o estado da sessão, entre os dois aplicativos. Isso pode ser resolvido com um aplicativo chamando o outro no lado do servidor por meio das informações de cookies do navegador do usuário. É claro que outro compartilhamento de informações entre aplicativos também pode ser feito por meio de roteamento de URL e seqüências de consulta, o que é uma abordagem natural do MVC.

Além disso, identificar os módulos apropriados para migrar primeiro pode ser um desafio, mas você pode começar com todas as novas funcionalidades desenvolvidas no MVC para impedir que mais coisas que acabam na garagem sejam migradas. Em seguida, talvez escolha seções que tenham um registro significativo de retrabalho ou correções de bugs a serem executadas a seguir, pois o aplicativo MVC se tornaria uma forma de refatoração, usando seu sistema antigo para estabelecer os resultados esperados, conforme sugerido. Não se esqueça de aproveitar também a testabilidade do MVC adicionando testes de unidade e testes de aceitação automática (por exemplo, SpecFlow / Watin) durante esta refatoração. Uma vantagem do último tipo de teste é que você pode verificar se eles passam no sistema antigo e, em seguida, aplicar os mesmos testes ao seu novo código para esta e futuras refatorações.