O que é o 'ciclo de vida da página' de uma página ASP.NET MVC, em comparação com o ASP.NET WebForms?

O que é o 'ciclo de vida da página' de uma página ASP.NET MVC, em comparação com o 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 a partir do ASP.NET WebForms.

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 alguém capaz de responder à minha pergunta já sabe tudo isso - estou apenas tentando fazer uma comparação do 'ciclo de vida', então pensei em começar preenchendo o que todos já sabemos)

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 principal na qual eu coloco conteúdo.
• Em um manipulador de eventos para cada página de conteúdo, carrego dados do banco de dados (principalmente somente leitura).
• Vinculo esses dados aos controles do ASP.NET que representam grades, listas suspensas ou repetidores. Todos esses dados 'vivem' dentro do HTML gerado. Algumas delas entram no ViewState (mas eu não vou entrar nisso demais!)
• Defino propriedades ou vinculo dados a determinados itens como controles Image ou TextBox na página.
• A página é enviada ao cliente renderizado como HTML não reutilizável.
• Tento evitar o uso do ViewState que não seja o mínimo que a página precisa.

Lado do cliente (não usando o 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 selecionar a partir de uma lista suspensa - é gerada uma postagem que aciona um evento C # no meu código atrás. Esse evento pode ir para o banco de dados, mas, o que quer que seja, uma página HTML completamente recém-gerada acaba sendo enviada de volta ao cliente.
• Posso usar o Page.Session para armazenar pares de valores-chave que preciso reutilizar mais tarde

Então, com o 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 há muito novo lá.

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

O tratamento de eventos de formulários da web não deve ser usado no MVC. Em vez disso, suas classes Controller e seus métodos de ação manipularão o carregamento de seus dados em um "modelo" que é passado para a visualização.

Embora a ligação de dados no estilo de formulário da Web seja possível no MVC, acho que essa não é a solução ideal. É melhor colocar seus dados em uma classe de modelo e digitar fortemente sua visualização para que você tenha acesso direto a esse modelo. Então basta usar a <%= ViewData.Model.SomeProperty %>sintaxe para acessar seus dados e exibi-los nos locais desejados. Quanto ao viewstate, minha recomendação é esquecer que ele existe.

Lembre-se de que uma das vantagens do uso do MVC é que você tem controle sobre o HTML que envia ao cliente. Aceite esse poder e tente encontrar soluções que permitam manter esse controle. Os controles Webform tentam ocultar o html de você e, como tal, tornam mais difícil personalizar o html quando necessário.

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

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

A sessão do asp.net pode ser usada conforme necessário.