Essa é uma pergunta frequente que recebo por e-mail ou às vezes em algum comentário aqui no blog: Quando devo usar ASP.Net MVC e quando devo usar Web Forms? Outra relacionada é: Quais os prós e os contras do ASP.Net MVC.

Vou tentar responder as duas perguntas considerando o estado atual do ASP.Net MVC, que é o release do Preview 5. Pode ser que até o lançamento, que ninguém sabe quando vai ser e que a Microsoft não comenta, as coisas mudem. Vamos lá.

Como eu sou um grande entusiasta deste novo framework, vou falar primeiro quando você deve usar, e seus prós. Você deve usar ASP.Net MVC quando:

• Precisar mais controle sobre o HTML gerado do que o proporcionado pelos controles e as webpages de Web Forms. Todo o HTML gerado é você quem controla. Mesmo nos métodos de auxílio, quem decide se vai utilizá-los é você.
• Quiser ter uma aplicação focada em padrões mais reconhecidos, inclusive no front-end. O padrão MVC é um padrão amplamente difundido e elogiado e é a base do ASP.Net MVC.
• Precisar de um front-end que se integre melhor com padrões de arquitetura reconhecidos, como o DDD. O Web Forms também permite esse tipo de integração, mas com ASP.Net MVC eu diria que ela soa mais natural.
• Quiser trabalhar com testes unitários também na interface com o usuário. Os controladores são totalmente testáveis, e como são eles que coordenam o fluxo de trabalho, é lá o maior foco dos testes.
• Quiser utilizar já com o ASP.Net Routing, sem ter que esperar o ASP.Net 4.0. O ASP.Net MVC já nos possibilita utilizar o Routing de maneira muito inteligente, podendo gerar as rotas como bem quisermos.
• Precisar de uma aplicação mais modular, inclusive no front-end. O ASP.Net MVC é muito bem dividido em módulos e partes.
• Quiser ter mais liberadade para extender alguns pedaços do framework (essa é ligada à anterior). Com ASP.Net MVC você pode substituir os controllers, o engine de View, a maneira de procurar Views, o framework de testes, etc, etc, etc. No ASP.Net MVC a Microsoft seguiu a recomendação de programar para interfaces ou classes abstratas. Quase tudo é plugável.
• Quiser utilizar XSLT, XML, texto puro, ou sei lá o que mais para renderizar as páginas web. Essa também segue da sua anterior. Com ASP.Net MVC, você pode gerar HTML utilizando Web Forms para sua View, mas não obrigatoriamente. Você pode utilizar outros motores de view para gerar o HTML.
• Tiver a intenção de gerar uma página menor em bytes. ASP.Net MVC não tem viewstate, e o HTML é totalmente controlado por você, e isso torna a página menor.
• Precisar ter dois forms HTML na mesma página. Isso é possível com ASP.Net MVC, mas não com Web Forms.

Quando você não deve utilizar o MVC, e deve seguir com Web Forms, ou seja, os contras do MVC e os prós do Web Forms. Você deve utilizar Web Forms quando:

• Sua aplicação já está concluída (ou com boa parte pronta) com Web Forms. Não faça uma aplicação meio MVC, meio Web Forms. Apesar de tecnicamente viável vai confundir os desenvolvedores que vão dar manutenção no futuro, e durante o desenvolvimento vai dar mais trabalho ainda para separar rotas, entender quem chama o que, etc. Se já está com Web Forms, segue com Web Forms.
• Tiver pouco tempo de desenvolvimento e a equipe não conhecer o padrão MVC, o framework ASP.Net MVC, ou os dois. Eu sei que em projeto nunca há tempo e tudo é para ontem, então essa recomendação deve ser usada com cautela. O ASP.Net MVC tem uma curva de aprendizado rápida, principalmente para que usou ASP3 (clássico e conhece bem o <%), portanto estou falando daqueles projetos que você já sabe que vai entrar para perder os finais de semanas e as noites.
• Você gostar muito do modelo proporcionado pelo Web Forms de ilusão de manutenção de estado proporcionado pelo Viewstate. Agora com o P5 isso foi melhorado bastante (veja o post sobre validadores para ver um exemplo do que estou falando), mas para alguns acho que isso vai ser um deal breaker.
• Precisar de controles muito inteligentes, que por enquanto, só o Web Forms tem. O calendário é o que me vem à mente de imediato. Pelo menos por enquanto vai te dar um bom trabalho fazer um calendário com ASP.Net MVC.  Pode ser que, agora que temos o Partial Rendering funcionando muito bem, alguma coisa venha por aí no formato de views parciais pré prontas. Seria ótimo. Se não vier agora, acredito que em algum momento esse tipo de coisa vai aparecer no ASP.Net MVC.
• Suas necessidades de AJAX ou manipulação de Javascript forem muito altas, ou você odeia programar Javascript. No segundo caso eu recomendo o Script#, mas tem gente que nem assim vai querer. Nesse caso, pode ser que você não tenha a mesma flexibilidade que o Web Forms vai lhe dar, já que quase todo o código para o AJAX e o Javascript são gerados para você.
• Você é fã de carteirinha de alguns controles complexos, como o gridview, os de membership, ou ainda, você gosta muito de databinding (arrasta o controle, chamada .Datasource, .Databind e acabou). Nesse caso você vai se sentir fazendo muito trabalho manualmente e pode não gostar. Lembre-se: não há, até o momento, web controls para ASP.Net MVC.
• Você precisar utilizar programação de webparts para o Sharepoint. Quem conhece as webparts e sua integração com o Sharepoint sabe como essa integração é sensacional. Eu duvido que seja possível bater esse nível de integração na versão 1.0 do ASP.Net MVC.

Lembrem-se que Web Forms é um produto com 6 anos de lançado, e 8 de desenvolvimento, enquanto o ASP.Net MVC nem foi lançado ainda. O Web Forms é uma tecnologia muito madura, que já atende maravilhosamente os anseios da comunidade de desenvolvimento, e já foi muito lapidado de lá para cá. Ainda assim, eu estou vendo o ASP.Net MVC como um framework que já tem que sair um pouco amadurecido, ou a comunidade vai demorar a adotá-lo, em vista do grande sucesso e da enorme facilidade trazidos pelo Web Forms.

O que vocês acham? Os seus novos projetos têm mais cara de ASP.Net MVC ou Web Forms?