Por que você usaria o MVC sobre formulários da Web?

Recentemente, um arquiteto descreveu nossa empresa como oferecendo uma solução Rolls-Royce (MVC) quando tudo que ele precisava era de um Toyota (Web Forms).

Estou curioso para descobrir o que você pensa sobre formulários da web e MVC como uma opção arquitetural.

A analogia da Rolls-Royce / Toyota é terrivelmente falha e enganosa. Um (ASP.NET MVC) não é simplesmente uma versão mais sofisticada ou mais cara do outro (ASP.NET WebForms). São abordagens muito diferentes para criar aplicativos da Web usando o ASP.NET.

Para mim, a maior diferença arquitetônica entre o MVC e o WebForms é como eles trabalham com o ambiente sem estado da Web: o WebForms trabalha duro para criar um conjunto de abstrações que ocultam a natureza sem estado da programação da Web, enquanto o MVC abraça o ambiente sem estado e trabalha com isto.

Cada abordagem tem seus benefícios e desvantagens, mas eu realmente gosto de como a criação de sites com MVC parece muito mais natural do que WebForms (com sua camada após camada de abstrações com vazamentos ).

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.

Uma solução ASP.NET MVC não precisa ser mais complicada do que uma solução WebForms. Pessoalmente, acho que o ASP.NET MVC é realmente muito mais simples que o WebForms, e definitivamente parece ser inerentemente mais limpo.

Pela minha experiência, muitas das estruturas MVC (ASP.NET, Rails, CodeIgniter, etc.) têm praticamente a mesma funcionalidade e convenções principais. WebForms é realmente um pato estranho do ponto de vista da web. Meu palpite é que a maioria dos programadores da Web seria muito mais rápida ao escolher o ASP.NET MVC do que os WebForms.

O principal motivo pelo qual você usaria o ASP.NET MVC sobre o ASP.NET WebForms é a testabilidade. Claro que você pode tipo WebForms de teste de unidade, mas isso requer estruturas de simulação e muita dor. A segunda razão é MVC faz com que seja um pouco mais fácil para preocupações distintas. Isso pode fornecer uma grande quantidade de reutilização de código e tornar seu código fracamente acoplado. Isso não significa que é impossível fazer o mesmo no ASP.NET com padrões como MVP.

A desvantagem do MVC é que você perde muita funcionalidade e isso foi incorporado aos WebForms na última década (quase quase). O MVC percorreu um longo caminho desde a sua criação para fornecer recursos semelhantes.

Quanto ao desempenho, alguém tem provas, de uma maneira ou de outra, de que a tecnologia é "mais rápida"?

Eu não acho que um seja melhor que o outro. Eu realmente gosto da estrutura MVC e a usei com grande sucesso, mas sempre me certifico de escolher a tecnologia que corresponde ao projeto.