Pergunta antiga, mas merece uma resposta mais detalhada, caso alguém ainda esteja tendo um dilema sobre isso.
Por fim, os webforms são uma solução de thin client, pelo que significa que você pressiona vários botões bonitos e o material do front end (cliente) é criado para você. Se você tem pessoas que sabem como implementá-lo em formulários da web e não há absolutamente nenhuma preocupação de manutenção / modificação e o site é completamente curto e descartável, não há nada de errado com essa abordagem. É possível aprender como fazer suas próprias coisas, mas, nesse caso, seria necessário conhecer as formas da web de coisas da Web que tentam proteger os desenvolvedores de aplicativos .NET e todas as coisas de formas da Web que fazem com que a maioria dos desenvolvedores da Web do lado do cliente deseje matar a Microsoft. engenheiros responsáveis.
Nos 99,5% de todos os outros cenários de casos de uso, paramos de tentar ocultar a Web dos desenvolvedores de aplicativos porque, na verdade, se você deseja escrever aplicativos da Web, é muito melhor aprender realmente como a Web funciona. A ironia das soluções de clientes grossos versus thin clients é que, inevitavelmente, a abordagem de thin client inevitavelmente incha a porcaria do seu front end e é tudo menos desempenho. Mais importante, essas soluções sempre tornaram as coisas inflexíveis como o inferno para as pessoas que realmente sabem o que estão fazendo e não querem ser limitadas pela estrutura em vigor.
Não há nada tão inútil quanto pegar alguém que sabe tudo sobre CSS, JavaScript, HTML, XHR e torná-lo completamente inútil, bloqueando-o a cada passo do caminho com uma estrutura que ...
Limpa todas as tags de script 'desnecessárias' nas tags head para impedir que você estrague as dependências de script. (é melhor deixar um 'gerenciador de scripts' lidar com isso para você) Concedido, ninguém os coloca lá em cima hoje em dia se eles sabem o que estão fazendo, mas isso é apenas uma bagunça.
Insiste em agrupar todo o HTML em uma tag de formulário ginormous. O HTML não permite formulários dentro de formulários; portanto, você cria formulários da maneira da Web ou de maneira alguma.
Cria como um "ciclo de vida" de 18 etapas para o que realmente deveria se resumir a reagir a eventos da interface do usuário, interagindo com o navegador para enviar mensagens ao servidor e depois reagir quando o servidor responder. Abstrair esse processo com uma grande pilha gigante de lixo nunca precisou acontecer (e para ser justo, a MS não é o único idiota que tentou fazer isso).
Na verdade, faz tudo o que pode para atrapalhar o uso de soluções que não são da web para problemas. Exemplo: quando eu era um desenvolvedor júnior do lado do cliente, passei o dia inteiro encontrando uma maneira de fazer um botão de envio na parte superior da página acionar um botão de envio na parte inferior da página (presumo que esse coisa de forma gigante). Normalmente, isso levaria 5 minutos, mas depois de algumas horas de engenharia reversa dos JavaScript responsáveis pelas formas da web, descobri que eles estavam entre outras coisas definindo uma propriedade que eu nem sabia na época que informa qual o último elemento de formulário a ter O foco era que, quando um botão de envio fosse clicado, apenas o botão oficial do Microsoft Submit (tm) funcionasse com relação à ativação de um manipulador oficial do Microsoft Submit (tm).
Portanto, não, Rolls-Royce vs Toyota, é completamente irracional. Eu diria mais: um Hyundai perfeitamente razoável pelo qual você paga muito em comparação com um Pinto projetado pela Microsoft com um sistema a bordo que faz curvas acentuadas de 90 graus automaticamente quando descobre que comprou gás ou óleo de alguém que não seja a Microsoft e detectou um parede conveniente para bater. Um carro ideal para o motorista fiel à marca suicida que não sabe nada sobre a web e quer jurar lealdade ao longo da vida à Microsoft.
Todo o .NET MVC é realmente, é simples e razoável, e não reinventa sua própria camada para dar um tapa na Web. Ele apenas funciona com o que está lá para ajudar a eliminar alguns clichês para você. Existem estruturas melhores / mais baratas / gratuitas disponíveis, mas se você já se trancou na coisa do .NET, poderia fazer muito pior.
Mas, falando sério, fique longe do! @ # $ Dos formulários da web. Está quase morto agora. Deixe ir. Diga a seus clientes que você fará isso por três vezes o dinheiro se eles também prometerem a você um contrato de suporte exclusivo e lucrativo por hora para quando eles realmente querem fazer algo novo ou diferente ou quando a porcaria começa a quebrar, porque nem a MS poderia se preocupe em continuar adicionando àquele gigante de um arquivo ajax.js de 10.000 linhas que eles retiram da sua DLL onde você não pode tocá-lo.