Quando favorecer ASP.NET WebForms em vez de MVC

Webforms vs. MVC parece ser um tópico quente no momento. Todo mundo que eu conheço diz que MVC é a próxima grande coisa. Pelas minhas pequenas pinceladas, parece ok, mas não, eu não acho que será o fim dos formulários da web.

Meu raciocínio, e o motivo pelo qual os formulários da web seriam escolhidos em vez do MVC, tem tem mais a ver com uma perspectiva de negócios do que com o que uma é melhor do que a outra.

Tempo / dinheiro são os maiores motivos pelos quais os formulários da web seriam escolhidos em vez do MVC.

Se a maioria de seus equipe conhece webforms 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, pular e fazer aquela página complexa que você precisa fazer são coisas muito diferentes. A curva de aprendizado é alta, então você precisa levar isso em consideração em seu orçamento.

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

Não estou dizendo que é uma abordagem 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 na equipe estão familiarizados com MVC.

Minha empresa fez recentemente três páginas de teste com MVC. Sentamos e as 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 comum. Agora temos uma camada extra de aninhamento.

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

Achei que havia muitos arquivos para 3 páginas, mas esse é o meu opinião pessoal.

Na minha opinião, você escolheria os formulários da web em vez do MVC se não tivesse tempo / dinheiro para investir na atualização do seu site para usar o MVC. Se você fizer uma abordagem meio árdua para isso, não será melhor do que os formulários da web que você tem agora. Pior, você pode até mesmo estar configurando esta tecnologia para o fracasso em sua empresa se ela for complicada, já que a alta administração pode vê-la como algo inferior ao que conhece.

Comentários

• Esta é uma boa resposta. Eu lhe dei +1 porque suas experiências pessoais são apreciadas. Mas, isso é um fracasso devido à falta de experiência / conjunto de habilidades dos desenvolvedores que pedi para evitar . Não estou convencido de que a Microsoft escolheria não marcar uma tecnologia como obsoleta simplesmente por temer a curva de aprendizado do MVC. Esse pode ser o caso, mas eu ‘ ainda não convencido.
• @ P.Brian.Mackey – Eu não ‘ disse que o desenvolvimento de formulários é mais rápido do que MVC. Você pediu para deixar esse argumento de fora. Discutir tempo e dinheiro para treinar sua equipe é um argumento diferente. A MS ganhou ‘ t marcar os formulários da web como obsoletos por um grande motivo: clientes corporativos passaram anos desenvolvendo clientes da web em formulários da web e conquistou ‘ Não pense em ter que investir tempo e dinheiro para atualizar.
• @Raynos – Se todos na equipe eram proficientes em MVC e sua empresa estava iniciando um novo projeto, então a única razão pela qual eu vi alguém escolhendo formulários da web é por escolha pessoal.
• Eu conheço ambas as tecnologias intimamente. Todos os meus projetos web são feitos com mvc e trabalho em uma empresa onde tenho total liberdade para fazer o que for melhor. Eu sempre escolho o MVC.
• Comecei com o Webforms e quando descobri o MVC mudei para ele. Eu não ‘ não sei como alguém poderia defender webforms. Ciclo de vida da página e um formulário para a página inteira? Você está brincando comigo? O construtor de sites do Yahoo provavelmente era o cliente pretendido para ele, mas mesmo eles não ‘ queriam aquele lixo.

Eu desenvolvi aplicativos ASP .Net WebForms por 3 anos e, após um dia fazendo um tutorial 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 fornecem um poder imenso e evitam a necessidade de fazer ligação de controle manual e elimina muitos erros relacionados à ligação. li>
• Você pode ter vários formulários em uma página. Esta era uma limitação séria dos WebForms.
• A web não tem estado e o MVC corresponde mais de perto à arquitetura da web. Os formulários da web apresentam o estado e os bugs você consegue 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 funcionar com ajax atualmente. Não é mais aceitável que a página inteira seja carregada. MVC torna o ajax muito melhor, mais fácil e mais eficiente com JQuery.
• Porque você pode ter vários formulários em uma página e porque a arquitetura é impulsionado por chamadas para urls, você pode fazer coisas funky como ajax carregar um formulário diferente, como um formulário de edição em sua página atual usando JQuery. Depois de perceber o que isso permite, você pode fazer coisas incríveis facilmente.
• ASP .Net WebForms não é apenas uma abstração sobre html, é extremamente complexa. Às vezes, você pegava um bug estranho e lutava com ele por muito mais tempo do que o necessário. Em muitos casos, você podia realmente ver o que ele estava fazendo de errado mas você não pode fazer nada sobre isso. Você acaba fazendo soluções alternativas estranhas.
• WebForms não é uma boa tecnologia para designers. Designers geralmente gostam de trabalhar com html diretamente. Em MVC, é uma visão, em WebForms é meio dia de trabalho.
• Como a plataforma da web está evoluindo rapidamente, os WebForms não vão acompanhar. ciente de novas tags ou recursos do HTML5, ele ainda renderá as mesmas coisas, a menos que você obtenha (frequentemente) controles caros de terceiros ou espere a Microsoft lançar uma atualização.
• Os controles em WebForms limitam você de muitas maneiras. No MVC, você pode simplesmente pegar uma biblioteca JQuery e integrá-la aos seus modelos.

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

Comentários

• +1 para apontando vários formulários. Além disso, o fato de que os webforms em HTML geram não é, na maioria das vezes, muito amigável com SEO (como em: grandes pedaços de viewstate no topo da página)
• Tenho que concordar 100% com esta resposta. No final do dia, os WebForms tornam as coisas do lado do cliente (html / navegador) muito mais difíceis. Você literalmente tem que lutar contra a estrutura para fazer algumas coisas. Uma página aspx termina com muito mais código devido aos controles do servidor do que uma página cshtml normalmente faz. @ šljaker Se você começar a desligar o ViewState e evitar os controles do servidor, você ‘ abandonou muitos dos WebForms naquele ponto. Não ‘ não vejo esse argumento como particularmente convincente.
• Você pode ter controles html simples em WebForms, ninguém o força a usar os controles de servidor. Você pode ter um formulário da Web totalmente sem estado, ninguém o força a usar o ViewState. Você pode usar ajax completo e jQuery em formulários da Web, ninguém o está restringindo de usar jQuery. Você pode implementar o roteamento de URL, ninguém o forçará a usar URL de base de arquivo estático. Desenhar manualmente uma página com CSS consome o tempo que o MVC precisa. Você pode criar uma página HTML diretamente no formulário da Web.
• @mjb: Se você não ‘ usa controles de servidor, ViewState e assim por diante, por que usar WebForms quando MVC está mais próximo do que você ‘ está fazendo? É ‘ é como dirigir um trator para o trabalho, mas não fazer nenhum offroad ou usar a pá / enxada ou barras estabilizadoras. Nesse ponto, por que não usar apenas um carro?
• @Tjaart Não é muito certo que você não possa ter vários formulários na página ASPNET.Você pode ter quantos formulários quiser na página ASPNET, mas pode ter apenas um formulário de servidor – formulário com runat = ” servidor ” atributo.

Eu enviei um e-mail para Scott Guthrie , um especialista em MVC da Microsoft. E provavelmente o homem mais qualificado para responder a essa pergunta. Ele foi gentil o suficiente para responder:

“Diferentes clientes procuram diferentes abordagens de programação e muitos amam WebForms e acham que é ótimo. Outros amam MVC e acho que é ó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 vários de vocês disseram.

Obrigado por todas as respostas.

Comentários

• Scott Guthrie inventou a estrutura MVC para ASP.NET durante um vôo de volta de Londres a Seattle em 2006/7. Pensando bem, ele praticamente inventou o .NET também ( en.wikipedia.org/wiki/Scott_Guthrie ). Chamá-lo de ” especialista ” é um eufemismo enorme 😉
• Isso ‘ uma boa resposta política de Scott Guthrie. Se ele próprio estivesse investindo em seu próprio aplicativo da Web, você ‘ veria um projeto MVC e qualquer coisa que não pudesse ‘ ser feito em MVC, Silverlight seria o substituto. Não ‘ tome isso como um comentário negativo para WebForms, acho que WebForms são ótimos para aplicativos internos de escopo menor que podem se beneficiar de componentes de terceiros, como os criados pela Telerik. Eu ‘ Fico feliz que a Microsoft esteja avançando com as duas tecnologias.
• ” Scott Guthrie inventou a estrutura MVC para ASP .NET durante um vôo ” Acho que realmente trivializa o MVC. Eu não ‘ não conheço Scott Guthrie, mas ‘ estou disposto a apostar que ele especulou como o MVC poderia ser implementado no ASP.NET por um tempo, e usei aquele longo voo para implementar um protótipo básico como uma prova de conceito.
• ” É por isso que estamos investindo em ambos. ” E quando vermos que os formulários da web começam a diminuir, vamos abandoná-lo impiedosamente, porque investir em um produto definitivamente morto não é do nosso interesse comercial.
• Até não é mais ensinado nas escolas, por muitos anos, sempre será aplicável no mundo dos negócios. Faculdades e escolas de segundo grau continuam oferecendo cursos introdutórios e avançados em vb.net. NÃO vai a lugar nenhum !!!

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

A resposta curta é:

• Use a ASP.NET MVC se você pretende construir adequadamente um aplicativo da web com programação moderna convenções e padrões adotados pela indústria para a plataforma ASP.NET. No lado negativo, espera-se que você saiba como HTML e os recursos do lado do cliente (Javascript, CSS) funcionam, bem como intensifique a mentalidade de programação MVC, que tem uma curva de aprendizado íngreme, mas chega a um fim repentino depois de apreendida.
• Use ASP.NET Web Forms se estiver usando ou quiser usar uma GUI -centric, RAD (Rapid Application Development) , abordagem arrastar e soltar para prototipar algo muito rapidamente, ou seja, botão de ação / comportamento da grade de dados conectado em 15 minutos, e a solução não se destina a ser algo suportado por desenvolvedores. Ou Use ASP.NET Web Forms se tiver experiência em desenvolvimento de GUI ou Windows Forms e desejar transferir seu conhecimento para a Web.

Mas, para ver isso de maneira adequada, você precisa entender a história de cada um.

O ASP.NET Web Forms foi a resposta da Microsoft para aqueles que construíram aplicações web dinâmicas usando Visual Basic 6 Ac controles tiveX, DLLs VB6 no servidor e ASP Classic. Na época, o desenvolvimento da web usando essas ferramentas da Microsoft era uma verdadeira bagunça. Junto com a totalidade do .NET Framework, que foi a saída da Microsoft essencialmente voltando à prancheta de como fazer programação de negócios produtiva na pilha do Windows, ASP.NET Web Forms era, em sua época, incrível e bonito.

A abordagem toda era dar aos desenvolvedores o melhor dos dois mundos de algo muito semelhante ao desenvolvimento de aplicativos do Windows, mas com o poder dos serviços de Internet.A ideia era que, assim como com um “Form” (uma janela) VB6 / WinForms, também uma página da web é 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 estão acostumados.

Para fazer um botão fazer algo, depois de arrastá-lo e soltá-lo, clique duas vezes nele no designer e pronto, você está no editor de código, dizendo ao formulário o que fazer quando esse “clique “evento acontece. Foi exatamente assim que os desenvolvedores de GUI do Windows criaram software usando ferramentas GUI de VB6 e ferramentas concorrentes, exceto que agora o código está sendo executado no servidor! Uau!

Essa era a tecnologia de 2002. Incrível e linda em seu tempo como uma resposta à internet habilitado para soluções de GUI para desenvolvimento RAD , trouxe uma sensação de poder para um mundo confuso de desenvolvedores de software que tinham objetivos de negócios que eles precisavam cumprir.

Infelizmente, esse modelo de programação enfatiza tanto a metáfora da programação da GUI do Windows que carrega consigo o fardo de seus detalhes de implementação necessários , toda a bagagem onerosa, ne essencial para acomodar os ciclos de vida do evento e esconder os detalhes desagradáveis do HTML simples e do script que esses componentes e controles de arrastar e soltar produziriam. E, no final do dia, os desenvolvedores que suportam aplicativos reais inevitavelmente tiveram que se aprofundar nesses componentes ou escrever seus próprios e, consequentemente, travariam batalhas com esta infraestrutura, batalhas que deixariam para trás pilhas sobre pilhas de pedaços, cabelos puxados e lágrimas.

Faça backup. Lave as mãos. Vejamos o problema de negócios novamente. Quais são nossos objetivos de negócios?

Precisamos construir 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 #). Nós realmente precisamos dessa metáfora da GUI do Windows para conduzir nossa metodologia de desenvolvimento? Por que não podemos apenas nos concentrar nos problemas do aplicativo e acabar com as metáforas da GUI?

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

O que realmente se traduz neste caso é:

1. Separação de interesses . Por exemplo, um componente de dados não precisa saber como seus dados serão renderizados, nem deve visualizar a marcação ser sobrecarregada com detalhes de configuração de conexão de banco de dados e, desta 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 para exposição aos detalhes do HTML e recursos relacionados . Em Web Forms, o HTML fica escondido, os desenvolvedores são desencorajados a se preocupar com isso. Na ASP.NET MVC, os desenvolvedores são encorajados a gerenciar esses detalhes; na verdade, é uma necessidade. A vantagem aqui é que o desenvolvedor pode reaprender a apreciar a semântica limpa de HTML, CSS e script, e trabalhar com isso em vez de contra ele.
3. Testabilidade de objetos de negócios . Os controladores e modelos são muito mais adequados para testes de unidade programáticos, de modo que as implementações podem ser validadas para atender aos objetivos de negócios e as alterações podem ser verificadas para que não sejam interrompidas. Com os Web Forms, era difícil testar porque os componentes não foram projetados para serem testados individualmente e toda a saída de desenvolvimento girava em torno de formulários de página e seus ciclos de vida de eventos com a sujeira da lógica de negócios e da lógica de apresentação profundamente entrelaçadas.

Observe que HTML já é uma linguagem de marcação de alto nível, assim como 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 o # 2, então, outro objetivo da ASP.NET MVC é permitir que os desenvolvedores organizem os detalhes do front-end de a parte de “visualização” de suas soluções e aproveite a rica base que o resto do setor construiu na plataforma de cliente front-end.

Você descobrirá que os desenvolvedores ASP.NET MVC se sentem em casa utilizando ricas bibliotecas Javascript e técnicas de modelagem do lado do cliente sem lutar com a arquitetura do lado do servidor. Este não era originalmente o caso do ASP.NET Web Forms, porque Web Forms não quer que você veja o HTML ou o script, exceto se você realmente precisar , caso em que, cuidado, não é para os fracos de coração .

Comentários

• Esta é uma boa resposta, mas os números 1 e 2 estão errados (o WF não requer um componente para saber onde estão seus dados vem de, é uma opção e você sempre adicionou HTML aos seus arquivos ASPX para suportar as tags asp que está renderizando. Você nunca precisou se aprofundar e lutar contra os controles, a menos que estivesse tentando acessar um recurso ASP não destinado ao desenvolvedor interação. Os pontos principais são testabilidade e padrão de design.)

Sou um convertido total para ASP.NET MVC e não olhei para trás, que disse que eu ainda tenho que manter vários aplicativos WebForms muito grandes. Aqui está minha opinião sobre isso:

WebForms
Use-os quando você tiver uma vida muito pesada ting a ver com 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 os registros. Sim, eu sei que o MVC 4 tem um tipo de lista Ajax realmente elegante que você pode usar e que funciona muito bem, mas, em nosso negócio, muitas vezes precisamos fazer algo funcionar ontem e as boas grades antigas funcionam muito bem e os usuários ficam felizes em estar capaz de percorrer uma grade com alegria. Para mim, essa é realmente a melhor coisa sobre WebForms para mim; mas, como Ryan apontou, WebForms podem ser uma grande bagunça porque você está jogando dos dois lados da cerca de um arquivo code-behind bacana. Pode ser uma rosa e um espinho ao mesmo tempo, para manter todas as suas coisas do tipo controlador misturadas com suas visões.

MVC
Use quando você realmente quiser lançar o seu próprio e tiver a oportunidade de iniciar um aplicativo do zero. Ter um aplicativo MVC claramente definido é um pouco mais trabalhoso para começar, mas seus benefícios em capacidade de manutenção superam o custo de configuração inicial. Se você deseja fazer interações Ajax interessantes, prefira escrever seu modelo com código, como limpar urls e rotas, e ser capaz de controlar todo o fluxo de seu aplicativo, então este é definitivamente o caminho a percorrer. Leva algum tempo para se acostumar no início, mas acho que é a melhor opção para aplicativos greenfield.

Em conclusão, para mim, tudo se resume a grades e! grades. 🙂

Comentários

• +1 para a bela imagem entregue com ” jogando em ambos os lados do cerca de um arquivo code-behind bacana “.
• Muito útil este aqui. Eu ‘ estou fazendo um aplicativo baseado em grade muito pesado e ‘ descartei silverlight, xbap e estava em um show entre estes dois.

Minha experiência:

• Escreveu projetos CakePHP por um ano.
• Concluiu um projeto de Webforms de médio porte em seis meses.
• Trabalhou em um projeto de Formulários do Windows por três anos.

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

Em seguida, experimentei o MVC e, tendo um controle mais direto sobre a saída (e alguma experiência com o paradigma MVC do CakePHP), consegui concluir aquele aplicativo simples exatamente do jeito que queria em cerca de meio dia.

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

Comentários

• @JimG – Uhh , qualquer coisa que envolva uma pessoa inserir registros sem associações interessantes em um banco de dados e fazer com que essa pessoa ou outra pessoa os leia / imprima em algum outro ponto pode ser basicamente estruturado usando uma estrutura MVC. Certo, isso não é ‘ a maioria dos aplicativos, mas ‘ é muito mais do que você pode fazer com o Formulários. Eu acho que seu -1 prova meu ponto.
• Que ‘ s 1/4 de um dia.
• Mas se os requisitos chegarem a ” Preciso de um aplicativo com duas funções, uma para registrar algumas informações, a outra para examiná-las e não ‘ realmente importa a aparência. ” Então, sim, isso ‘ é bastante factível.
• desculpe, mas desenvolver um aplicativo de formulários da web para inserir e visualizar dados é tão simples que pode ser feito em poucas horas. criar a estrutura de um aplicativo MVC, controladores, visualizações e ações, levaria a mesma quantidade de tempo, mas não levará você a um produto acabado.
• @Dementic Normalmente, para um aplicativo MVC simples, constrói-se modelos e, a seguir, scaffolds controladores e visualizações e / ou gera scaffolds controladores / visualizações. Nada realmente demorado lá.

Eu prefiro webforms porque meu plano de fundo é o desenvolvimento do Windows.

A velocidade de desenvolvimento é uma questão chave, e posso facilmente passar um problema para alguém na Índia para consertar durante a noite com os formulários; também, se eu tiver um problema de velocidade em uma página, um livro realmente bom sobre asp.net velocidade é útil (Rick Kiessig é o cara).

webforms é para ex-pessoas do Windows mvc é para pessoas da web

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

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

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

Comentários

• você poderia explicar em mais detalhes por que você acha isso?
• Eu acho que abstrair o REST básico está de volta, todo o modelo de postback está de volta, a forma como o html / css é transmitido com base no editor de GUI é ruim , a ênfase em coisas como assistentes e GUIs para configurar coisas é ruim, os URLs são ruins, etc. e assim por diante

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

3 a 4 anos atrás, desenvolvi 2 a 3 projetos de sites usando Webforms. Naquela época, MVC não existia ou eu não ouvia falar dele. O desenvolvimento foi naturalmente (eu estava vindo do desenvolvimento de formulários Win sem experiência anterior em desenvolvimento web) rápido para mim, já que eu não preciso aprender HTML em detalhes e os controles da web ajudaram muito (muito, isso tornou a vida mais fácil) .

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

Alguns dias atrás, eu tive uma ideia para um e pensei em desenvolvê-lo: desta vez em MVC (já que é falado em todos os lugares, além disso eu precisava aprender também, então escolhi MVC). O projeto ainda está em fase de desenvolvimento, pois ainda estou aprendendo e construindo juntos.

Portanto, as principais diferenças que encontro entre as duas são as seguintes: –

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

• Para alguém vindo do desenvolvimento web em alguma outra tecnologia, MVC será favorecido, uma vez que zomba disso o mais recente de todos eles.

• O desenvolvimento é mais fácil e mais limpo em MVC se você estiver equipado com bons conhecimentos de HTML e CSS

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

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

Eu não vi essa consideração apresentada entre as 15 respostas existentes para este tópico ainda, mas acho que sim Vale a pena considerar.

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

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

Comentários

• + 1 Certamente um argumento razoável para Webforms. Meu medo é que as equipes sigam essa mentalidade para evitar aprender coisas novas. MVC é preenchido com muitos padrões que podem não ser familiares para uma equipe. Aprender esses tipos de padrões e implementá-los leva a uma melhor aderência aos princípios SOLID, o que se traduz em uma melhor manutenção geral. Essas técnicas comprovadas também são a verdadeira chave para a reutilização.

Nosso motivo para não ir para MVC alguns anos atrás, era uma tecnologia imatura da Microsoft. Ao longo dos últimos anos, estamos agora em uma versão mais madura (4) e a MS parece ter percebido onde está indo com isso.No entanto, ainda relutamos em desenvolver os principais aplicativos LOB usando MVC, pois os recursos que queremos usar na versão 4 exigem um servidor Windows 2012 (re web sockets via IIS8). Acho que em mais 1 ano aceitaremos melhor o MVC, pois espero que mais controles de terceiros estejam disponíveis, a tecnologia terá se instalado e teremos a infraestrutura para suportá-la.

Comentários

• Você se importaria de listar alguns desses recursos que você diz que exigem o Windows Server 2012?

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

O tempo para treinar aprendendo MVC ou hora de conseguir uma entrega. Todas essas coisas são importantes para escolher uma ou outra abordagem.

Não é que uma seja melhor do que a outra, simplesmente ambas as abordagens ou frameworks têm prós e contras.

Pessoalmente, eu sou a favor do MVC 3, Recomendo que você tente obter sua própria experiência, mas devo dizer que o programa em MVC é uma forma limpa, divertida, flexível, extensível, segura e estruturada.

Atenciosamente,

A única razão pela qual eu escolheria WebForms em vez de MVC é porque você tem muito mais controles de UI de terceiros para WebForms do que MVC. Eu escolhi MVC porque trabalhei muito com WebForms e quero trabalhar com algo novo / novo, mas ainda da loja da MS 🙂

Basicamente, nada impede que você desligue o viewstate em WebForms e use ViewModels e se / para loops em vez de vinculação de modelo e controles do lado do servidor.

Este é o código WebForms ou MVC:

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

A única limitação que encontrei nos WebForms é que se você usar injeção / inversão de dependência de Controle, você não pode ter injeção de construtor, pois as páginas de WebForms devem ter construtor sem parâmetros, então você tem que usar injeção de propriedade. Isso é realmente tão importante?

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

As formas da Web ASP.NET oferecem muito controle sobre o cliente do lado do servidor, com acesso direto para quase tudo. Essencialmente, sua visualização e controlador são um no mesmo, o que lhe dá muito poder e, na maioria das vezes, muita confusão.

ASP.NET MVC separa a visualização e o controlador destacando o acoplamento estreito de um arquivo .aspx e o arquivo .aspx.cs que os acompanha em formulários da web.

Basicamente, a diferença é ter muito mais (normalmente todo) o processamento para exibir dados para o arquivo de visualização, e deixando a lógica de negócios e o resto no controlador, mantendo-os limpos por convenção, mas também com menos acesso um ao outro do que o permitido pelos formulários da web.

Comentários

• Então, QUANDO os formulários da web devem ser preferidos em relação ao MVC? Isso não responde à pergunta dos autores originais.
• @WeekendWarrior – Sim, quando você quiser mais acesso do lado do servidor ao cliente, escolha formulários da web. Se você quiser mais desacoplamento do cliente / servidor em seu código, escolha MVC. No final do dia, os dois fazem exatamente a mesma coisa. Os filtros de redirecionamento fazem a mesma coisa que os urls MVC e você pode mover o código dos webforms para uma camada intermediária separada para desacoplá-lo ainda mais. weblogs.asp.net/scottgu/archive/2010/01/24/…
• Em relação ao seu terceiro ponto, essa lógica de negócios acaba no arquivo .aspx.cs – acho que isso é culpa dos desenvolvedores. Ele ‘ não / deveria / estar lá. Em formulários da web, o .aspx é a ” view “, o .aspx.cs é o ” controlador ” equivalente, destinado a processar o código que se relaciona diretamente apenas com a IU, pesquisando uma camada de negócios ou camada de fachada de negócios de granulação grossa. O fato de as pessoas colocarem lógica de negócios em .aspx.cs é apenas uma programação ruim. Eles também podem colocar a lógica de negócios na visualização do MVC! MVC não ‘ t força a separação dessas coisas.
• Essencialmente, ele está mais certo do que outras respostas postadas aqui. ASP.net é a ideia básica por trás de uma família de tecnologia da Web modular criada pela Microsoft. O módulo ASP.net MVC pode ser um exagero temporário, mas com certeza não é o último, tudo começa com ASP.net, então quando escolher ASP.net, se você não acha que MVC não é para você, talvez você esteja mais interessado em algo então OWIN ou …, algo mais avançado, ou fez seu próprio framework para suas tarefas. Você pode nem precisar do ASP.MVC e pular e ir Owin ou Katana, mas até lá, use o asp.net

Na minha opinião, eles são relacionados o suficiente e têm aproximadamente as mesmas capacidades que deveriam vir por preferência.

Um grande desenvolvedor de WebForms pode produzir um produto tão poderoso quanto um grande desenvolvedor de MVC. Mas o grande desenvolvedor de WebForms tentando se forçar a adotar o MVC vai falhar. O mesmo vale para um grande desenvolvedor MVC dando uma chance aos WebForms.

Eles não são entidades completamente separadas e, enquanto a Microsoft continuar oferecendo suporte a ambos, acredito que você continuará a ver um grupo misto de desenvolvedores excepcionais para cada um.

Isso é tudo uma questão de escolha pessoal, assumindo que todos nós somos proficientes com a tecnologia que usamos. Eu tenho usado a abordagem de design de WebForms por muitos anos e devo dizer que a única desvantagem é que, devido a sua abordagem simplista, muitas pessoas não perdem tempo para descobrir seus vastos recursos.

Recentemente usei MVC para concluir um projeto e, embora eu goste bastante da abordagem de design para o desenvolvimento de aplicativos (que oferece mais controle, limpar urls, SOC, etc.), não há realmente muito que ele oferece , que WebForms não podem “t. Na verdade, o surgimento de jQuery e seu funcionamento com WebForms (bem como MVC) tornou esses argumentos menos problemáticos. E quando as pessoas falam sobre separação de interesses como uma vantagem que o MVC tem sobre o MVP, eu pergunto quanto eles sabem sobre programação orientada a objetos e o quanto eles colocam em uso o princípio de abstração e polimorfismo.

Atualmente, estou confortável usando ambas as tecnologias e eu escolho e escolho com base na situação. Francamente falando, é bom para você, mas a verdade é que nem todo mundo gasta seu tempo para aprender em profundidade o que uma tecnologia específica é capaz.

Comentários

• Idem em os vastos recursos dos formulários da web. A maioria das pessoas está vendo as rodinhas de treinamento dos formulários da web e comparando isso com o MVC.
• Não faz sentido aprender uma abstração sobre HTML e Javascript nos dias de hoje (mesmo em 2013). Isso ‘ não será bom para suas oportunidades futuras. HTML e Javas Cript está muito bem do jeito que está. Lutar é uma batalha perdida.

Quando me deparo com um problema de programação, costumo recorrer à web para obter respostas. O Webforms tem toneladas de informações / componentes para fazer quase tudo. Em MVC, devido a menos fontes online e as camadas de abstrações necessárias para fazer algo funcionar, colocou um limite nas coisas que eu poderia fazer antes. O total de MVC mata minha produtividade como desenvolvedor, embora com Webforms ele não seja mais. Por enquanto, estou me limitando aos webforms até que o MVC amadureça o suficiente para substituí-lo.

Bem, WebForms têm mais recursos de aprendizagem disponíveis (simplesmente devido ao fato de ser mais antigo) e, portanto, novos programadores que não estão “informados” terão mais probabilidade de encontrar informações sobre essa tecnologia mais antiga em oposição a coisas mais novas como MVC.

Programadores sênior / experientes são mais velhos e serão mais proficientes na tecnologia mais antiga devido ao fato de que a programaram por mais tempo do que tem no mais novo.

A menos que você possa gastar dinheiro e esforço para tornar seus caras tão proficientes em MVC quanto em aplicativos WebForms, você sem dúvida tentará adiar a atualização para o novo 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 escrito inteiramente em WebForms, valeria a pena o esforço e dinheiro para integrar o MVC nele?

Conforme declarado por um comentarista anterior, o MVC também impede que você alcance o mesmo nível de interface com o controlador, como seria possível com WebForms. Embora eu “seja totalmente a favor do lado” Impedir que o usuário empacote / aprenda “das coisas, ainda pode ser irracionalmente problemático para as equipes implantar / implementar um programa que fanaticamente adere a esse paradigma para tudo o que escrevem.

Acho que a lacuna entre essas duas tecnologias não é tão grande quanto costumava ser.

• Formulários da web podem usar o mecanismo de roteamento que o MVC usa (ou algo muito semelhante).
• O gerenciador de scripts pode combinar scripts, carregar de um CDN e até mesmo atrasar o carregamento de scripts.

Para responder diretamente à sua pergunta, acho que se trata de preferência e / ou qual é o projeto. Ambos têm uma abordagem significativamente diferente para o desenvolvimento. Pessoalmente, tenho trabalhado na mudança para MVC, mas ainda gosto de trabalhar com Webforms. Acho que a resposta para se você deve usar MVC ou Webforms é para você decidir experimentando ambas as tecnologias.

Comentários

• Webforms e MVC recomendam uma atitude de desenvolvimento web radicalmente diferente por padrão, isso é importante , poucos desenvolvedores se desviam de ” o padrão “. Ambos podem ser usados para alcançar a mesma coisa.