Maior vantagem de usar o ASP.Net MVC vs web forms

Quais são algumas das vantagens de usar um sobre o outro?

As principais vantagens do ASP.net MVC são:

  1. Permite o controle total sobre o HTML renderizado.

  2. Fornece separação clara de preocupações (SoC).

  3. Habilita Desenvolvimento Orientado a Testes (TDD) .

  4. Fácil integração com frameworks JavaScript.

  5. Seguindo o design da natureza sem estado da web.

  6. URLs RESTful que permitem SEO.

  7. Nenhum evento ViewState e PostBack

A principal vantagem do ASP.net Web Form é:

  1. Ele fornece desenvolvimento RAD

  2. Modelo de desenvolvimento fácil para desenvolvedores que vêm do desenvolvimento de winform.

ASP.NET Web Forms e MVC são dois frameworks web desenvolvidos pela Microsoft – ambos são boas escolhas. Nenhum dos frameworks da web deve ser substituído pelo outro nem há planos de tê-los “mesclados” em uma única estrutura. O suporte e o desenvolvimento contínuos são feitos em paralelo pela Microsoft e nenhum deles estará “indo embora”.

Cada uma dessas estruturas da web oferece vantagens / desvantagens – algumas das quais precisam ser consideradas ao desenvolver um aplicativo da web. Uma aplicação web pode ser desenvolvida usando tecnologia – pode tornar mais fácil o desenvolvimento de uma aplicação específica, selecionando uma tecnologia versus outra e vice-versa.

Formulários da Web ASP.NET:

  • O desenvolvimento suporta estado • Dá a ilusão de que um aplicativo da Web está ciente do que o usuário vem fazendo, semelhante aos aplicativos do Windows. Isto torna a funcionalidade de ‘assistente’ um pouco mais fácil de implementar. Formulários da Web fazem um ótimo trabalho em esconder muito dessa complexidade do desenvolvedor.
  • Desenvolvimento Rápido de Aplicativos (RAD) • A capacidade de simplesmente “entrar” e começar a entregar formulários da web. Isso é contestado por alguns membros da comunidade MVC, mas pressionado pela Microsoft. No final, tudo se resume ao nível de conhecimento do desenvolvedor e com o que eles estão confortáveis. O modelo de formulários da web provavelmente tem menos de uma curva de aprendizado para desenvolvedores menos experientes.
  • Caixa de ferramentas de controle maior • O ASP.NET Web Forms oferece uma checkbox de ferramentas muito maior e mais robusta (controles da Web), enquanto o MVC oferece um conjunto de controles mais primitivo que conta mais com controles rich client via jQuery (Javascript).
  • Madura • Existe desde 2002 e há uma abundância de informações sobre questões, problemas, etc. Oferece mais controle de terceiros – é necessário considerar os kits de ferramentas existentes.

ASP.NET MVC:

  • Separação de interesses (SoC) • Do ponto de vista técnico, a organização do código dentro do MVC é muito limpa, organizada e granular, facilitando (esperançosamente) o dimensionamento de um aplicativo da Web em termos de funcionalidade. Promove um excelente design do ponto de vista do desenvolvimento.
  • Integração mais fácil com ferramentas do lado do cliente (ferramentas avançadas de interface de usuário) • Mais do que nunca, os aplicativos da web estão cada vez mais se tornando tão ricos quanto os aplicativos que você vê em seus desktops. Com o MVC, ele oferece a capacidade de se integrar com tais kits de ferramentas (como o jQuery) com maior facilidade e com mais facilidade do que no Web Forms.
  • Search Engine Optimization (SEO) Amigável / Stateless • As URLs são mais amigáveis ​​para os mecanismos de busca (ou seja, mywebapplication.com/users/ 1 – recuperar o usuário com um ID de 1 vs mywebapplication / users / getuser.aspx (id passado na session)). Da mesma forma, como o MVC é sem estado, isso elimina a dor de cabeça dos usuários que geram vários navegadores da mesma janela (colisões de session). Na mesma linha, o MVC adere ao protocolo da web sem estado, em vez de “lutar” contra ele.
  • Funciona bem com desenvolvedores que precisam de alto grau de controle • Muitos controles em formulários da Web do ASP.NET geram automaticamente muito do HTML bruto que você vê quando uma página é renderizada. Isso pode causar dores de cabeça para os desenvolvedores. Com o MVC, é melhor ter controle total com o que é renderizado e não há surpresas. Ainda mais importante, é que os formulários HTML normalmente são muito menores do que os formulários da Web, o que pode equivaler a um aumento de desempenho – algo a ser considerado seriamente.
  • Test Driven Development (TDD) • Com o MVC, você pode criar mais facilmente testes para o lado da Web. Uma camada adicional de testes fornecerá ainda outra camada de defesa contra o comportamento inesperado.

Autenticação, autorização, configuração, compilation e implantação são todos os resources compartilhados entre as duas estruturas da web.

Qualquer pessoa com idade suficiente para se lembrar do ASP clássico se lembrará do pesadelo de abrir uma página com código misturado com html e javascript – até mesmo a menor página era uma dor para descobrir o que diabos estava fazendo. Eu posso estar errado, e espero que esteja, mas o MVC parece voltar a esses velhos tempos ruins.

Quando o ASP.Net apareceu, ele foi saudado como o salvador, separando o código do conteúdo e permitindo que os web designers criassem o html e os codificadores trabalhassem no código por trás. Se não quiséssemos usar o ViewState, o desligamos. Se não quiséssemos usar código por algum motivo, poderíamos colocar nosso código dentro do html como o ASP clássico. Se não quisermos usar o PostBack, redirecionamos para outra página para processamento. Se não quiséssemos usar os controles ASP.Net, usamos controles html padrão. Poderíamos até mesmo interrogar o object Response se não quiséssemos usar o ASP.Net runat = “server” em nossos controles.

Agora alguém em sua grande sabedoria (provavelmente alguém que nunca programou ASP clássico) decidiu que é hora de voltar aos dias de misturar código com conteúdo e chamá-lo de “separação de interesses”. Claro, você pode criar um html mais limpo, mas você pode usar o ASP clássico. Dizer “você não está programando corretamente se você tem muito código dentro de sua visão” é como dizer “se você escreveu um código bem estruturado e comentado no ASP clássico é muito mais limpo e melhor que ASP.NET”

Se eu quisesse voltar a mixar código com conteúdo, eu olharia para o desenvolvimento usando PHP, que tem um ambiente bem mais maduro para esse tipo de desenvolvimento. Se houver tantos problemas com o ASP.NET, por que não corrigir esses problemas?

Por último, mas não menos importante, o novo mecanismo Razor significa que é ainda mais difícil distinguir entre html e code. Pelo menos poderíamos procurar abrir e fechar tags, ou seja, < % e%> no ASP, mas agora a única indicação será o símbolo @.

Pode ser hora de mudar para o PHP e esperar mais 10 anos para alguém separar o código do conteúdo mais uma vez.

Se você está trabalhando com outros desenvolvedores, como PHP ou JSP (e eu estou supondo que os rails) – você vai ter um tempo muito mais fácil de converter ou colaborar em páginas, porque você não vai ter todos aqueles asp.net ‘desagradável’ events e controles em todos os lugares.

O problema com o MVC é que, mesmo para “especialistas”, consome muito tempo valioso e exige muito esforço. As empresas são impulsionadas pela coisa básica “Solução rápida que funciona”, independentemente da tecnologia por trás dela. WebForms é uma tecnologia RAD que economiza tempo e dinheiro. Tudo o que requer mais tempo não é aceitável pelas empresas.

  1. AJAX adequado, por exemplo, JSONResults sem bobagens de postback de página parcial.
  2. sem viewstate +1
  3. Nenhuma renomeação dos IDs HTML.
  4. Limpe HTML = sem inchaço e tendo uma chance decente de renderizar páginas compatíveis com XHTML ou padrões.
  5. Não há mais gerado javascript AXD.

A maior vantagem para mim seria a clara separação entre suas camadas de Modelo, Visualização e Controlador. Isso ajuda a promover um bom design desde o início.

Eu não vi nenhuma vantagem em MVC sobre ASP.Net. 10 anos atrás, a Microsoft apresentou a UIP (User Interface Process) como a resposta ao MVC. Foi um fracasso. Fizemos um grande projeto (4 desenvolvedores, 2 designers, 1 testador) com a UIP naquela época e foi um pesadelo.

Não basta entrar em bandwagon por causa do Hype. Todas as vantagens listadas acima já estão disponíveis no Asp.Net (com mais ótimos ajustes [ Novos resources do Asp.Net 4 ] no Asp.Net 4).

Se a sua equipe de desenvolvimento ou uma única família de desenvolvedores com Asp.Net apenas se ativer a ela e criar produtos bonitos rapidamente para satisfazer seus clientes (quem paga por suas horas de trabalho). O MVC vai consumir seu valioso tempo e produzir os mesmos resultados que o Asp.Net 🙂

Francis Shanahan,

  1. Por que você chama postback parcial como “bobagem”? Este é o recurso principal do Ajax e tem sido muito bem utilizado na estrutura do Atlas e maravilhosos controles de terceiros, como o Telerik.

  2. Eu concordo com o seu ponto sobre a viewstate. Mas se os desenvolvedores tiverem o cuidado de desabilitar o viewstate, isso pode reduzir bastante o tamanho do HTML que é renderizado, tornando a página leve.

  3. Apenas os controles do servidor HTML são renomeados no modelo de formulário da Web do ASP.NET e não em controles html puros. Seja o que for, por que você está tão preocupado se a renomeação é feita? Eu sei que você quer lidar com muitos events de javascript no lado do cliente, mas se você projetar suas páginas da web de forma inteligente, você pode definitivamente obter todos os id que você quer

  4. Mesmo o ASP.NET Web Forms atende aos padrões XHTML e não vejo nenhum inchaço. Isso não é uma justificativa de por que precisamos de um padrão MVC

  5. Mais uma vez, por que você está incomodado com JavaScript AXD? Por que isso te machuca? Esta não é uma justificativa válida novamente

Até agora, sou fã de desenvolver aplicativos usando formulários da Web ASP.NET clássicos. Por exemplo: Se você quiser vincular uma lista suspensa ou um gridview, você precisa de um máximo de 30 minutos e não mais de 20 linhas de código (mínimo claro). Mas no caso do MVC, converse com os desenvolvedores como é a dor.

A maior desvantagem do MVC é que estamos voltando aos dias do ASP. Lembre-se o código de espaguete de misturar o código do servidor e HTML ??? Oh meu Deus, tente ler uma página aspx do MVC misturada com JavaScript, HTML, JQuery, CSS, tags de servidor e o que não … Qualquer corpo pode responder a essa pergunta?

Os formulários da Web também ganham com maior maturidade e suporte de provedores de controle de terceiros, como a Telerik.

Em webforms, você também pode renderizar quase todo o html manualmente, exceto algumas tags como viewstate, eventvalidation e similar, que podem ser removidas com PageAdapters. Ninguém força você a usar o GridView ou algum outro controle do lado do servidor que tenha saída de renderização html ruim.

Eu diria que a maior vantagem do MVC é o SPEED!

Em seguida é a separação forçada de preocupação. Mas não proíbe colocar toda a lógica BL e DAL dentro do Controller / Action! É apenas a separação de visão, o que pode ser feito também em webforms (padrão MVP, por exemplo). Muitas coisas que as pessoas mencionam para o mvc podem ser feitas em webforms, mas com algum esforço adicional.
A principal diferença é que a solicitação vem para o controlador, não para a visualização, e essas duas camadas são separadas, não conectadas via class parcial como em webforms (aspx + code behind)

Meus 2 centavos:

  • Os formulários ASP.net são ótimos para o desenvolvimento rápido de aplicativos e agregam valor aos negócios rapidamente. Eu ainda o uso para a maioria dos aplicativos de intranet.
  • O MVC é ótimo para o Otimização de mecanismos de pesquisa, pois você controla o URL e o HTML em maior grau
  • MVC geralmente produz uma página muito mais enxuta – sem viewstate e mais limpa HTML = tempos de carregamento rápidos
  • MVC fácil para armazenar em cache partes da página. -MVC é divertido de escrever: – opinião pessoal 😉

O MVC permite que você tenha mais de um formulário em uma página. Um pequeno recurso que conheço, mas é útil!

Também o padrão MVC que sinto torna o código mais fácil de manter, esp. quando você revisitar depois de alguns meses.

Controlador MVC:

  [HttpGet] public ActionResult DetailList(ImportDetailSearchModel model) { Data.ImportDataAccess ida = new Data.ImportDataAccess(); List data = ida.GetImportDetails(model.FileId, model.FailuresOnly); return PartialView("ImportSummaryDetailPartial", data); } 

Visualização MVC:

  @foreach (Data.ImportDetailData detail in Model) {  } 
Unique IdError TypeFieldMessageState
@detail.UniqueID@detail.ErrorType@detail.FieldName@detail.Message@detail.ItemState

Quão difícil é isso? Sem ViewState, sem ciclo de vida da página BS … Apenas código puro e eficiente.

Eu posso ver as duas únicas vantagens para sites menores: 6) URLs RESTful que permitem SEO. 7) Sem events ViewState e PostBack (e maior desempenho em geral)

O teste para sites pequenos não é um problema, nem as vantagens de design quando um site é codificado adequadamente, de qualquer maneira, o MVC ofusca e dificulta as alterações. Ainda estou decidindo se essas vantagens valem a pena.

Eu posso ver claramente a vantagem do MVC em sites maiores de vários desenvolvedores.

O principal benefício que vejo é forçar o projeto a uma estrutura mais testável. Isso pode muito facilmente ser feito com webforms também (padrão MVP), mas requer que o desenvolvedor tenha uma compreensão disso, muitos não.

Webforms e MVC são ferramentas viáveis, ambos se destacam em diferentes áreas.

Eu pessoalmente uso formulários da web, pois desenvolvemos principalmente aplicativos B2B / LOB. Mas nós sempre fazemos isso com um padrão MVP, com o qual podemos alcançar 95 +% de cobertura de código para nossos testes unitários. Isso também nos permite automatizar o teste em propriedades do valor da propriedade webcontrols é exposto através da visão, por exemplo

 bool IMyView.IsAdminSectionVisible{ get{return pnlAdmin.Visible;} get{pnlAdmin.Visible=value;} } 

) Eu não acho que este nível de teste é tão facilmente alcançado no MVC, sem poluir o meu modelo.

Você não se sente mal sobre o uso de ‘controles não pós-back’ mais – e descobrir como smush-los em um ambiente tradicional asp.net.

Isso significa que controles de javascript modernos (livres de usar), como este ou este ou este, podem ser usados ​​sem que se tente encheckboxr um pino redondo em uma sensação de buraco quadrado.

Controles javascript modernos, bem como solicitações JSON, podem ser manipulados com muita facilidade usando o MVC. Lá podemos usar muitos outros mecanismos para postar dados de uma ação para outra. É por isso que preferimos o MVC em formulários web. Também podemos construir páginas leves.

Minha opinião pessoal é que, Maior desvantagem de usar ASP.Net MVC é que CODE BLOCKS misturado com HTML
inferno html para os desenvolvedores que mantêm isso …