Qual é o ‘ciclo de vida da página’ de uma página ASP.NET MVC, comparado com ASP.NET WebForms?

Qual é o ‘ciclo de vida da página’ de uma página ASP.NET MVC, comparado com ASP.NET WebForms?

Estou tentando entender melhor essa questão “simples” para determinar se as páginas existentes que eu tenho em um site (muito) simples podem ser facilmente convertidas dos WebForms do ASP.NET.

Uma “conversão” do processo abaixo ou um ciclo de vida alternativo seria o que estou procurando.

O que estou fazendo atualmente:

(sim, eu sei que qualquer um capaz de responder a minha pergunta já sabe tudo isso – eu estou apenas tentando obter uma comparação do ‘ciclo de vida’ então eu pensei em começar preenchendo o que todos nós já conhecemos)

Renderizando a página:

  • Eu tenho uma página mestra que contém meu modelo básico
  • Eu tenho páginas de conteúdo que me dão regiões nomeadas da página mestra na qual eu coloquei o conteúdo.
  • Em um manipulador de events para cada página de conteúdo, carrego dados do database (principalmente somente leitura).
  • Eu vinculo esses dados a controles ASP.NET que representam grades, menus suspensos ou repetidores. Todos esses dados ‘vivem’ dentro do HTML gerado. Algumas delas entram no ViewState (mas eu não vou entrar muito nisso!)
  • Eu defino propriedades ou vinculo dados a determinados itens como controles Image ou TextBox na página.
  • A página é enviada para o cliente processado como HTML não reutilizável.
  • Eu tento evitar o uso de ViewState diferente do que a página precisa, no mínimo.

Lado do cliente (não usando ASP.NET AJAX):

  • Eu posso usar o JQuery e alguns truques desagradáveis ​​para encontrar controles na página e executar operações neles.
  • Se o usuário seleciona em um menu suspenso – um postback é gerado, o que aciona um evento C # no meu code-behind. Este evento pode ir para o database, mas o que quer que ele faça, uma página HTML completamente gerada acaba sendo enviada de volta ao cliente.
  • Eu posso usar Page.Session para armazenar pares de valores chave que eu preciso reutilizar mais tarde

Então, com MVC, como esse ‘ciclo de vida’ muda?

Vou tentar comentar sobre cada um dos pontos que você mencionou:

Suas páginas mestras ainda existem no MVC e são usadas para fornecer um layout consistente para o site. não muito novo lá.

Suas páginas de conteúdo se tornarão visualizações no mundo MVC. Eles ainda fornecem as mesmas áreas de conteúdo para suas páginas mestras.

O manipulador de events de formulários da web não deve ser usado no MVC, em vez disso, suas classs de Controlador e seus methods de ação manipularão o carregamento de seus dados em um “modelo” que é passado para a exibição.

Embora a binding de dados do estilo webform seja possível no MVC, acho que não é a solução ideal. É melhor colocar seus dados em uma class de modelo e digitar fortemente sua visualização para que você tenha access direto a esse modelo. Então é simplesmente uma questão de usar a syntax <%= ViewData.Model.SomeProperty %> para acessar seus dados e exibi-los nos locais desejados. Quanto à viewstate, minha recomendação é esquecer que ela existe.

Lembre-se de que uma das vantagens de usar o MVC é que você tem controle sobre o HTML enviado para o cliente. Abrace esse poder e tente encontrar soluções que lhe permitam manter esse controle. Os controles do Webform tentam ocultar o html de você e, assim, dificultam a personalização do html quando necessário.

Eu recomendo altamente JQuery ou uma das outras bibliotecas javascript igualmente poderosas. Mas aprenda a usá-los para acessar o HTML DOM diretamente e evitar os problemas de identificação de controles webform.

Você pode usar o jquery para conectar-se à seleção suspensa no lado do cliente e enviar solicitações de estilo padrão ou ajax. Essas solicitações podem retornar novas páginas, redirecionamentos, fragments de HTML ou até mesmo dados JSON que podem ser usados ​​para atualizar a página existente.

A session asp.net pode ser usada conforme necessário.