Quel est le «cycle de vie de page» d'une page ASP.NET MVC, par rapport aux WebForms ASP.NET?

Quel est le «cycle de vie de page» d'une page ASP.NET MVC, par rapport aux WebForms ASP.NET?

J'essaie de mieux comprendre cette question «simple» afin de déterminer si les pages existantes que j'ai dans un site (très) simple peuvent être facilement converties à partir de WebForms ASP.NET.

Soit une «conversion» du processus ci-dessous, soit un cycle de vie alternatif serait ce que je recherche.

Ce que je fais actuellement:

(oui, je sais que quiconque est capable de répondre à ma question sait déjà tout cela - j'essaie juste d'obtenir une comparaison du `` cycle de vie '', alors j'ai pensé que je commencerais par remplir ce que nous savons déjà tous)

Rendu de la page:

• J'ai une page maître qui contient mon modèle de base
• J'ai des pages de contenu qui me donnent des régions nommées à partir de la page maître dans laquelle je place le contenu.
• Dans un gestionnaire d'événements pour chaque page de contenu, je charge les données de la base de données (principalement en lecture seule).
• Je lie ces données à des contrôles ASP.NET représentant des grilles, des listes déroulantes ou des répéteurs. Ces données «vivent» toutes dans le HTML généré. Une partie entre dans ViewState (mais je n'entrerai pas trop dans cela!)
• Je définis des propriétés ou je lie des données à certains éléments tels que les contrôles Image ou TextBox sur la page.
• La page est envoyée au client en tant que HTML non réutilisable.
• J'essaie d'éviter d'utiliser ViewState autre que ce dont la page a besoin au minimum.

Côté client (sans utiliser ASP.NET AJAX):

• Je peux utiliser JQuery et quelques astuces désagréables pour trouver des contrôles sur la page et effectuer des opérations sur eux.
• Si l'utilisateur sélectionne dans une liste déroulante - une publication est générée qui déclenche un événement C # dans mon codebehind. Cet événement peut aller à la base de données, mais quoi qu'il fasse, une page HTML entièrement nouvellement générée finit par être renvoyée au client.
• Je peux utiliser Page.Session pour stocker les paires valeur / clé que je devrai réutiliser plus tard

Alors avec MVC, comment ce «cycle de vie» change-t-il?

Je vais essayer de commenter chacun des points que vous avez mentionnés:

Vos pages maîtres existent toujours dans MVC et sont utilisées pour fournir une mise en page cohérente au site. pas grand chose de nouveau là-bas.

Vos pages de contenu deviendront des vues dans le monde MVC. Ils fournissent toujours les mêmes zones de contenu à vos pages maîtres.

La gestion des événements des formulaires Web ne doit pas être utilisée dans MVC, à la place vos classes Controller et leurs méthodes d'action géreront le chargement de vos données dans un «modèle» qui sera transmis à la vue.

Bien que la liaison de données de style formulaire Web soit possible dans MVC, je trouve que ce n'est pas la solution optimale. Mieux vaut placer vos données dans une classe de modèle et taper fortement votre vue afin d'avoir un accès direct à ce modèle. Ensuite, il suffit d'utiliser la <%= ViewData.Model.SomeProperty %>syntaxe pour accéder à vos données et les afficher aux emplacements souhaités. Quant à viewstate, ma recommandation est d'oublier qu'il existe même.

N'oubliez pas que l'un des avantages de l'utilisation de MVC est que vous contrôlez le code HTML que vous envoyez au client. Acceptez ce pouvoir et essayez de trouver des solutions qui vous permettent de garder ce contrôle. Les contrôles Webform tentent de vous cacher le html et, par conséquent, rendent plus difficile la personnalisation du html lorsque vous en avez besoin.

Je recommande vivement JQuery ou l'une des autres bibliothèques javascript tout aussi puissantes. Mais apprenez à les utiliser pour accéder directement au DOM HTML et éviter les problèmes de déformation des identifiants des contrôles de formulaires Web.

Vous pouvez utiliser jquery pour vous connecter à la sélection déroulante côté client et soumettre des demandes de style standard ou ajax. Ces requêtes peuvent renvoyer de nouvelles pages, des redirections, des fragments html ou même des données JSON qui peuvent être utilisées pour mettre à jour la page existante.

La session asp.net peut être utilisée selon les besoins.