Quando favorecer o ASP.NET WebForms sobre o MVC

Eu sei que a Microsoft disse

O ASP.NET MVC não substitui os WebForms.

E alguns desenvolvedores dizem que o WebForms é mais rápido do que o MVC. Mas acredito que a velocidade da codificação se reduz ao nível de conforto com a tecnologia, por isso não quero respostas nesse sentido.

Dado que o ASP.NET MVC oferece ao desenvolvedor mais controle sobre seus aplicativos, por que os WebForms não são considerados obsoletos? Como alternativa, quando devo favorecer o WebForms sobre o MVC para um novo desenvolvimento?

Webforms vs. MVC parece ser um tópico importante no momento. Todo mundo que eu conheço considera o MVC a próxima grande coisa. Pelas minhas ligeiras brincadeiras, parece bom, mas não, acho que não será o fim dos webforms.

Meu raciocínio e o motivo pelo qual os webforms seriam escolhidos em relação ao MVC têm mais a ver com uma perspectiva de negócios do que com o que um é melhor que o outro.

Tempo / dinheiro são as principais razões pelas quais os webforms seriam escolhidos em vez do MVC.

Se a maioria da sua equipe conhece formulários da Web e você não tem tempo para atualizá-los no MVC, o código que será produzido pode não ser de qualidade. Aprender o básico do MVC e, em seguida, entrar e fazer aquela página complexa que você precisa fazer são coisas muito diferentes. A curva de aprendizado é alta, portanto, você deve levar isso em consideração no seu orçamento.

Se você tem um site grande escrito tudo em formulários da web, pode estar mais inclinado a criar novas páginas em formulários da web para não ter dois tipos muito diferentes de páginas no site.

Não estou dizendo que é uma abordagem de tudo ou nada aqui, mas torna seu código mais difícil de manter se houver uma divisão de ambos, especialmente se nem todos da equipe estiverem familiarizados com o MVC.

Minha empresa recentemente fez três páginas de teste com o MVC. Nos sentamos e os projetamos. Um problema que encontramos é que a maioria de nossas telas tem a funcionalidade Visualizar e editar na mesma página. Acabamos precisando de mais de um formulário na página. Nada demais, exceto que não usaríamos nossa página mestre. Tivemos que reformular isso para que as páginas de formulários da Web e as páginas MVC pudessem usar a mesma página mestre para uma aparência e comportamento comuns. Agora temos uma camada extra de aninhamento.

Precisávamos criar uma estrutura de pastas totalmente nova para essas páginas, para que ela seguisse a separação adequada do MVC.

Eu senti que havia muitos arquivos para 3 páginas, mas essa é minha opinião pessoal.

Na minha opinião, você escolheria formulários da web em vez do MVC se não tiver tempo / dinheiro para investir na atualização do site para usar o MVC. Se você fizer uma abordagem meio arriscada, isso não será melhor do que os webforms que você possui agora. Pior, você pode até estar configurando essa tecnologia para falhas em sua empresa se ela estiver bagunçada, pois a alta gerência pode vê-la como algo inferior ao que eles sabem.

Desenvolvi aplicativos ASP .Net WebForms por 3 anos e, após um dia realizando um tutorial do MVC, fui vendido. MVC é quase sempre a melhor solução. Por quê?

• O ciclo de vida da página é mais simples e mais eficiente
• Não existem controles além dos controles html. Você não precisa depurar sua saída para ver o que o ASP .Net está gerando.
• Os ViewModels oferecem imenso poder e evitam a necessidade de vincular manualmente o controle, além de eliminar muitos erros relacionados à vinculação.
• Você pode ter vários formulários em uma página. Essa foi uma limitação séria dos WebForms.
• A web é sem estado e o MVC corresponde à arquitetura da web mais de perto. As Webforms apresentam o estado e os bugs que você possui, apresentando o ViewState. O ViewState é automático e funciona em segundo plano, portanto nem sempre se comporta da maneira que você deseja.
• Os aplicativos da Web precisam trabalhar com ajax atualmente. Não é aceitável ter carregamentos de página inteira mais. O MVC torna o ajax muito melhor, mais fácil e mais eficiente com o JQuery.
• Como você pode ter vários formulários em uma página e como a arquitetura é direcionada por chamadas para URLs, você pode fazer coisas divertidas, como o ajax, carregar um formulário diferente, como um formulário de edição na sua página atual usando o JQuery. Depois de perceber o que isso permite, você pode fazer coisas incríveis com facilidade.
• O ASP .Net WebForms não é apenas uma abstração sobre html, é extremamente complexo. Às vezes, você recebe um bug estranho e luta com ele por muito mais tempo do que o necessário. Em muitos casos, você pode realmente ver o que estava fazendo de errado, mas não consegue fazer nada a respeito. Você acaba fazendo soluções estranhas.
• WebForms não cria uma boa tecnologia para designers. Os designers geralmente gostam de trabalhar com html diretamente. No MVC, é uma visualização; nas WebForms, é meio dia de trabalho.
• À medida que a plataforma da Web está evoluindo rapidamente, os WebForms não acompanham. Ele não está ciente das novas tags ou recursos do HTML5; ainda assim renderizará o mesmo material, a menos que você obtenha (muitas vezes) controles de terceiros caros ou aguarde a Microsoft emitir uma atualização.
• Os controles nos WebForms limitam você de várias maneiras. No MVC, você pode simplesmente pegar uma biblioteca JQuery e integrá-la aos seus modelos.

Sei que alguns dos problemas acima foram abordados até certo ponto à medida que o WebForms evolui, mas essa foi a minha experiência original. Em suma, seria extremamente difícil encontrar um caso de negócios para WebForms, a menos que um projeto já o esteja usando.

Enviei um email para Scott Guthrie , especialista em MVC da Microsoft. E provavelmente o homem mais qualificado para responder a essa pergunta. Ele teve a gentileza de responder:

"Diferentes clientes procuram diferentes abordagens de programação e adoram WebForms e acham ótimo. Outros amam o MVC e acham ótimo. É por isso que estamos investindo em ambos".

Então, para mim, isso diz que não é um problema técnico. É mais um "problema leve", se você quiser. Um de preferência pessoal. Isso está de acordo com o que muitos de vocês disseram.

Obrigado por todas as respostas.

Esta é uma pergunta obsoleta com muitas respostas, mas nenhuma tinha a resposta que eu esperava que fosse listada.

A resposta curta é:

• Use o ASP.NET MVC se você pretende criar corretamente um aplicativo Web com convenções de programação modernas e padrões adotados pelo setor para a plataforma ASP.NET. No lado negativo, você deverá saber como o HTML e os recursos do lado do cliente (Javascript, CSS) funcionam, além de aumentar a mentalidade de programação do MVC, que possui uma curva de aprendizado acentuada, mas atinge um fim repentino quando é apreendida.
• Use o ASP.NET Web Forms se você estiver usando ou quiser usar uma abordagem de arrastar e soltar, centrada na GUI , RAD (Rapid Application Development) para criar protótipos de algo muito rapidamente, por exemplo, comportamento de botão / grade de dados conectado dentro 15 minutos, e a solução não se destina a ser algo suportado pelos desenvolvedores. Ou, use ASP.NET Web Forms se você tem experiência em desenvolvimento de GUI ou Windows Forms e deseja transferir seu conhecimento para a Web.

Mas, para analisar isso corretamente, você precisa entender a história de cada um.

O ASP.NET Web Forms foi a resposta da Microsoft para aqueles que estavam criando aplicativos Web dinâmicos usando controles ActiveX do Visual Basic 6, DLLs do VB6 no servidor e ASP Classic. Na época, o desenvolvimento da Web usando essas ferramentas da Microsoft era uma verdadeira bagunça. Juntamente com a totalidade do .NET Framework, que foi o resultado da Microsoft voltando basicamente à prancheta sobre como fazer programação de negócios produtiva na pilha do Windows, o ASP.NET Web Forms era, na época, incrível e bonito.

Toda a abordagem foi oferecer aos desenvolvedores o melhor dos dois mundos, algo muito semelhante ao desenvolvimento de aplicativos Windows, mas com o poder dos serviços de Internet. A idéia era que, assim como em um "Formulário" do VB6 / WinForms (uma janela), uma página da Web também é um formulário (como uma janela, consulte) , e nesse formulário você pode arrastar e soltar rótulos, caixas de texto, grades de dados, botões e outras coisas às quais os desenvolvedores de GUI do VB / WinForms estavam acostumados.

Para fazer um botão fazer alguma coisa, depois de arrastá-lo e soltá-lo, basta clicar duas vezes nele no designer e selecionar o editor de código, dizendo ao formulário o que fazer quando esse evento de "clique" acontecer. Foi exatamente assim que os desenvolvedores da GUI do Windows criaram software usando as ferramentas GUI do VB6 e as ferramentas concorrentes, mas agora o código está em execução no servidor! Uau!

Esta foi a tecnologia de 2002. Surpreendente e bonito em sua época, como resposta às soluções de GUI da Internet para o desenvolvimento de RAD , trouxe uma sensação de poder a um mundo confuso de desenvolvedores de software que tinham objetivos de negócios que precisavam realizar.

Infelizmente, esse modelo de programação enfatiza tanto a metáfora da programação da GUI do Windows que carrega consigo o ônus de seus detalhes de implementação necessários, toda a bagagem onerosa necessária para acomodar os ciclos de vida do evento e afastar os feios detalhes do HTML simples e script que esses componentes e controles de arrastar e soltar produziriam. E no final do dia, os desenvolvedores que suportam aplicativos reais inevitavelmente precisavam cavar fundo nesses componentes ou escrever seus próprios e, conseqüentemente, travavam batalhas com essa infraestrutura, batalhas que deixavam para trás pilhas e mais pilhas de cruft, cabelos arrancados e lágrimas.

Cópia de segurança. Lave suas mãos. Vejamos o problema de negócios novamente. Quais são os nossos objetivos de negócios?

Precisamos criar e gerenciar aplicativos da web . Nossas restrições são que temos a World Wide Web, que fica em HTTP, HTML, Javascript e CSS, e no servidor temos regras de negócios, bancos de dados e um pequeno punhado de ótimas linguagens de programação (por exemplo, C #). Realmente precisamos dessa metáfora da GUI do Windows para orientar nossa metodologia de desenvolvimento? Por que não podemos simplesmente focar nos problemas de aplicativos e acabar com as metáforas da GUI?

É aqui que entra o ASP.NET MVC. Tudo começou com uma rebelião de desenvolvedores que se autodenominavam "Alt.Net" que queriam voltar aos princípios de desenvolvimento de software adequados e puros. Chega de confusão e confusão, concentre-se apenas nos objetivos de negócios e nas melhores práticas de software.

O que isso realmente se traduz neste caso é:

1. Separação de preocupações . Por exemplo, um componente de dados não precisa saber como seus dados serão renderizados, nem a marcação deve ser sobrecarregada com os detalhes de configuração da conexão com o banco de dados e, dessa forma, um desenvolvedor pode se concentrar em sua área de preocupação ao editar e código de teste.
2. Exposição e suporte total à exposição ao âmago da questão do HTML e recursos relacionados . Nos Web Forms, o HTML está escondido, os desenvolvedores são desencorajados a se incomodar com isso. No ASP.NET MVC, os desenvolvedores são incentivados a gerenciar esses detalhes; na verdade, é uma necessidade. A vantagem aqui é que o desenvolvedor pode aprender novamente a apreciar a semântica limpa de HTML, CSS e script e trabalhar com ele em vez de contra ele.
3. Testabilidade de objetos de negócios . Controladores e modelos são muito mais adequados para teste de unidade programática, para que as implementações possam ser validadas para atender aos objetivos de negócios, e é possível verificar as alterações para que não quebrem. Com os Web Forms, era difícil testar, pois os componentes não eram projetados para serem testados individualmente e toda a saída do desenvolvimento girava em torno dos formulários das páginas e dos ciclos de vida de seus eventos, com a imundície da lógica de negócios e da lógica de apresentação profundamente entrelaçada.

Observe que o HTML já é uma linguagem de marcação de alto nível, assim como o Javascript é uma linguagem de programação de alto nível. A história toda teria sido diferente se estivéssemos lidando com a linguagem Assembly e C.

Expandindo a segunda posição, outro objetivo do ASP.NET MVC é permitir que os desenvolvedores organizem os detalhes do front-end da parte 'view' de suas soluções e tirem vantagem da rica base que o restante do setor construiu a plataforma do cliente front-end.

Você descobrirá que os desenvolvedores do ASP.NET MVC se sentem em casa utilizando bibliotecas Javascript avançadas e técnicas de modelagem do lado do cliente sem brigar com a arquitetura do lado do servidor. Esse não era originalmente o caso dos Formulários da Web do ASP.NET, porque os Formulários da Web não querem que você veja o HTML ou o script, exceto se você realmente tiver que , nesse caso, cuidado, não é para os fracos de coração.

Eu sou um completo e total convertido para o ASP.NET MVC e não olhei para trás, e disse que ainda preciso manter vários aplicativos WebForms muito grandes. Aqui está a minha opinião:

WebForms
Use-os quando tiver algum trabalho pesado sério relacionado a grades. Os controles de grade são realmente muito bons quando você tem um conjunto de dados simples que se encaixa perfeitamente em um formato tabular e deseja fornecer uma maneira simples para os usuários atualizarem registros. Sim, eu sei que o MVC 4 tem uma coisa realmente impressionante do tipo lista Ajax que você pode usar, que funciona muito bem, mas, em nossos negócios, muitas vezes precisamos fazer algo funcionar ontem e boas redes antiquadas funcionam muito bem e os usuários ficam felizes em estar capaz de percorrer uma grade com alegria. Para mim, isso é realmente a melhor coisa sobre WebForms para mim; mas, como RyanAs WebForms apontadas podem ser uma bagunça, porque você está jogando os dois lados da cerca a partir de um arquivo bacana de código por trás. Pode ser uma rosa e um espinho ao mesmo tempo para manter todas as suas coisas do tipo controlador controladas com suas visões.

MVC
Use isso quando você realmente quiser criar o seu próprio e tiver a oportunidade de iniciar um aplicativo do zero. Ter um aplicativo MVC claramente definido é um pouco mais trabalhoso, mas seus benefícios em manutenção superam o custo de configuração inicial. Se você deseja fazer interações interessantes com o Ajax, prefira escrever seu modelo com código, como URLs e rotas limpas, e poder controlar todo o fluxo do seu aplicativo, então este é definitivamente o caminho a seguir. Demora um pouco para se acostumar no começo, mas acho que é a melhor opção para aplicativos greenfield.

Em conclusão, para mim, tudo se resume a grades e! Grades. :)

Minha experiência:

• Escreveu projetos CakePHP por um ano.
• Concluiu um projeto de Webforms de tamanho médio em seis meses.
• Trabalhou em um projeto Windows Forms por três anos.

Após essa experiência, tentei escrever outro aplicativo usando formulários da web e fiquei frustrado depois de lutar por um dia com o modo como os formulários da web tentam proteger o desenvolvedor da realidade de que estão desenvolvendo um aplicativo que usa html, javascript e css.

Tentei o MVC e, tendo um controle mais direto sobre a saída (e alguma experiência com o paradigma MVC do CakePHP), consegui concluir esse aplicativo simples exatamente do jeito que eu queria em cerca de 1/2 por dia.

A disponibilidade de estruturas de interface do usuário poderosas como o jQuery elimina muito o apelo de abrir mão do controle direto da saída em favor do uso de componentes de interface do usuário muitas vezes volumosos pré-criados.

Eu prefiro webforms porque meu background é o desenvolvimento de janelas.

A velocidade do desenvolvimento é uma questão-chave, e posso facilmente passar um problema para alguém da Índia para corrigir os formulários da noite para o dia, além disso, se eu tiver um problema de velocidade em uma página, um livro realmente bom sobre a velocidade do asp.net é útil (Rick Kiessig é o homem).

webforms é para ex windows people mvc é para web people

mas, no mundo moderno, onde Rick escreveu um livro incrível, com servidores aumentando a velocidade diária e codificadores baratos na Índia, bem, os webforms têm a vantagem

Meus 2 centavos é sempre usar o ASP.NET MVC para novos projetos, se você tiver a opção. Na minha opinião, webforms não é uma boa maneira de desenvolver aplicativos web, ponto final.

Eu acho que abstrair o REST básico é ruim, todo o modelo de postagem é ruim, a maneira como o html / css é entregue com confiança no editor da GUI é ruim, a ênfase em coisas como assistentes e GUIs para configurar as coisas é ruim, os URLs são ruins.

Li todas as respostas e acha que minha experiência pessoal acrescentaria algo às respostas acima.

Há três ou quatro anos, desenvolvi 2-3 projetos de sites usando Webforms. Naquela época, o MVC não estava por perto ou eu não ouvi falar. O desenvolvimento foi naturalmente (eu vinha do desenvolvimento do Win-forms sem experiência anterior em desenvolvimento da Web) rápido para mim, pois não preciso aprender HTML em detalhes e os controles da Web ajudaram muito (muito, facilitou a vida) .

Agora, depois de todo esse tempo, eu não estava trabalhando em nenhum projeto da Web até recentemente e apenas construindo alguns aplicativos do Windows usando o WPF.

Poucos dias atrás, eu tive uma idéia para um site e pensei em desenvolvê-lo: desta vez no MVC (já que falamos sobre todos os lugares, além de eu precisar aprender também, então escolho o MVC). O projeto ainda está em fase de desenvolvimento, pois ainda estou aprendendo e construindo juntos.

Então, as principais diferenças que eu acho que são as seguintes:

• Para quem vem do desenvolvimento do Windows, os formulários da Web sempre serão favoráveis. Asp.net curva de aprendizado para um desenvolvedor do Windows é um pouco íngreme

• Para alguém que vem do desenvolvimento web em alguma outra tecnologia, o MVC será o favorito, pois zomba da última de todas.

• O desenvolvimento é mais fácil e limpo no MVC se você estiver equipado com um bom conhecimento de HTML e CSS

• A implantação ainda é um problema. Nos formulários da web, era necessário copiar e colar. Mas, isso requer que algumas coisas sejam feitas.

Em suma, os dois ficarão aqui por um tempo.

Ainda não vi essa consideração entre as 15 respostas existentes para este tópico, mas acho que vale a pena considerar.

Da minha experiência, o Web Forms é mais semelhante ao Win Forms e ao WPF do que o MVC. Diante disso, acho que podemos considerar a escolha de formulários da Web quando a equipe tiver mais experiência nesse tipo de tecnologia ou quando o projeto de formulários da Web fornecerá uma interface para o mesmo conjunto de dados que um Win Forms existente (ou desenvolvido simultaneamente) ou Projeto WPF. Isso permite que os desenvolvedores cruzem projetos com mais facilidade, pois a lógica do aplicativo pode ser bastante semelhante entre os dois.

Como outras respostas apontaram, o desenvolvimento na estrutura MVC é mais semelhante ao desenvolvimento web em Ruby, PHP, Python etc. do que seus colegas da Microsoft; então, naturalmente, a escolha do MVC pode ser influenciada pela experiência das equipes nessas áreas, juntamente com os fatores apresentados em outras respostas.

Nosso motivo para não ir ao MVC há alguns anos foi que era uma tecnologia imatura da Microsoft. Nos últimos anos, estamos agora em uma versão mais madura (4) e a MS parece ter descoberto para onde estão indo com isso. No entanto, ainda estamos relutantes em desenvolver aplicativos LOB importantes usando o MVC, pois os recursos que queremos usar na versão 4 exigem um servidor Windows 2012 (soquetes da Web via IIS8). Acho que em mais um ano estaremos mais aceitando o MVC, pois esperamos que mais controles de terceiros estejam disponíveis, a tecnologia tenha se estabelecido e teremos a infraestrutura para apoiá-lo.

Esta decisão depende das suas preferências, dos seus requisitos ou mesmo do seu conhecimento e experiência.

O tempo para treinar o aprendizado do MVC ou o tempo para obter uma entrega. Tudo isso importa para escolher uma ou outra abordagem.

Não é que um seja melhor que outro, simplesmente a abordagem ou a estrutura tem prós e contras.

Pessoalmente, sou a favor do MVC 3, recomendo que você experimente sua própria experiência, mas preciso dizer que o programa no MVC é uma maneira limpa, divertida, flexível, extensível, segura e estruturada.

Saudações,

A única razão pela qual eu escolheria as WebForms em vez do MVC é porque você tem muito mais controles de interface do usuário de terceiros para WebForms do que o MVC. Escolho o MVC porque trabalhei demais com WebForms e quero trabalhar com algo novo / novo, mas ainda da loja MS:)

Basicamente, nada impede que você desative o viewstate no WebForms e use ViewModels e loops if / for em vez de vinculação de modelo e controles do lado do servidor.

É este código WebForms ou MVC:

<% foreach (var item in Model.Items) { %>
<p><%: item.Name %></p>
<% } %>

A única limitação que encontrei no WebForms é que, se você usar Injeção de Dependência / Inversão de Controle, não poderá ter injeção de construtor, pois as páginas WebForms devem ter construtor sem parâmetros, portanto, é necessário usar injeção de propriedade. Isso é realmente um grande negócio?

O ASP.NET MVC é realmente uma resposta para o Ruby, e a nova e moderna maneira (IMO) de dissociar o navegador (cliente) do servidor o máximo possível.

O ASP.NET Webforms oferece muito controle sobre o cliente do lado do servidor, com acesso direto a praticamente tudo. Essencialmente, sua visão e controle são os mesmos, o que lhe dá muita energia e, na maioria das vezes, muita confusão.

O ASP.NET MVC separa a exibição e o controlador desanexando o acoplamento rígido de um arquivo .aspx e o arquivo .aspx.cs que os acompanha nos formulários da web.

Essencialmente, a diferença é ter muito mais (normalmente todo) do processamento para exibir dados no arquivo de visualização e deixar a lógica de negócios e o restante no controlador, mantendo-os mais limpos por convenção, mas também com menos acesso a cada diferente dos formulários da web permite.

Na minha opinião, eles estão relacionados o suficiente e têm aproximadamente os mesmos recursos que deveriam ser preferidos.

Um ótimo desenvolvedor de WebForms pode produzir um produto igualmente poderoso como um ótimo desenvolvedor de MVC. Mas o grande desenvolvedor de WebForms que tenta forçar-se a adotar o MVC está em falta. O mesmo vale para um grande desenvolvedor de MVC, dando uma chance ao WebForms.

Elas não são entidades completamente separadas e, enquanto a Microsoft continuar suportando as duas, acredito que você continuará vendo um grupo misto de desenvolvedores excepcionais para cada uma.

Trata-se de escolha pessoal, supondo que todos nós tenhamos conhecimento da tecnologia que usamos. Uso a abordagem de design do WebForms há muitos anos e devo dizer que a única desvantagem é que, devido à sua abordagem simplista, muitas pessoas não demoram a descobrir suas vastas capacidades.

Recentemente, usei o MVC para concluir um projeto e, embora eu goste da abordagem de design para o desenvolvimento de aplicativos (que oferece mais controle, URLs limpos, SOC etc.), na verdade não há muito que ele forneça, que os WebForms não podem. De fato, o surgimento do jQuery e seu funcionamento com WebForms (assim como MVC) tornaram esses argumentos menos problemáticos. E quando as pessoas falam sobre a separação de preocupações como uma vantagem que o MVC tem sobre o MVP, pergunto o quanto elas sabem sobre programação orientada a objetos e o quanto colocam em uso o princípio de abstração e polimorfismo.

Atualmente, estou confortável em usar as duas tecnologias e escolho e escolho com base na situação. Francamente, depende de você, mas a verdade é que nem todo mundo gasta seu tempo para aprender em profundidade do que uma determinada tecnologia é capaz.

Quando me deparo com um problema de programação, frequentemente busco respostas na web. Webforms tem toneladas de informações / componentes para fazer praticamente qualquer coisa. No MVC, devido ao menor número de fontes on-line e as camadas de abstrações necessárias para fazer algo funcionar, colocou um limite nas coisas que eu poderia fazer uma vez. O total do MVC mata minha produtividade como desenvolvedor, enquanto os Webforms não são. Então, por enquanto, continuarei com os formulários da Web até o MVC amadurecer o suficiente para substituí-lo.

Bem, as WebForms têm mais recursos de aprendizado disponíveis (simplesmente devido ao fato de serem mais antigas) e, portanto, novos programadores que não estão "informados" terão mais chances de encontrar informações sobre essa tecnologia mais antiga, em oposição a coisas mais recentes, como MVC .

Programadores seniores / experientes são mais velhos e serão mais proficientes na tecnologia mais antiga, devido ao fato de terem programado mais tempo do que na nova.

A menos que você possa gastar o dinheiro e o esforço para tornar seus funcionários tão proficientes em MVC quanto em aplicativos WebForms, sem dúvida tentará adiar a atualização para a nova plataforma pelo maior tempo possível.

Portanto, apresenta vários problemas logísticos: Os benefícios do MVC superam o custo em termos de menor qualidade e tempo de implantação? Se eu tiver um site totalmente escrito em WebForms, valeria a pena o esforço e dinheiro para integrar o MVC a ele?

Conforme declarado por um comentarista anterior, o MVC também impede que você atinja o mesmo nível de interface com o controlador que seria possível com os WebForms. Embora eu seja a favor do lado "Evite que o usuário encha / aprenda", ainda pode ser excessivamente problemático para as equipes implantar / implementar um programa que se apega fanaticamente a esse paradigma em tudo o que escreve.

Eu acho que a diferença entre essas duas tecnologias não é tão grande quanto costumava ser.

• Os formulários da Web podem usar o mecanismo de roteamento usado pelo MVC (ou algo muito semelhante).
• O gerenciador de scripts pode combinar scripts, carregar a partir de uma CDN e até atrasar o carregamento dos scripts.

Para responder diretamente à sua pergunta, acho que se resume a preferência e / ou qual é o projeto. Ambos adotam uma abordagem significativamente diferente do desenvolvimento. Pessoalmente, tenho trabalhado no MVC, mas ainda gosto de trabalhar com Webforms. Eu acho que a resposta para saber se você deve usar MVC ou Webforms é para você decidir experimentando as duas tecnologias.