ASP.NET MVC 2 en action
Figure 1 - La relation entre le modèle, la vue et le contrôleur
· Ligne continue : indique une association directe.
· Ligne pointillé : indique une association indirecte.
I. Exemple d’une application MVC
Etape 1 :
Créer un projet de type : ASP.NET MVC2 Web Application
Figure 2 - Boite de dialogue de création d'un nouveau projet. Choix de projet Template ASP.NET MVC 2
Figure 3 - Ne pas ajouter le test unitaire
On aura un projet composé de la hiérarchie suivante :
|
Etape 2 : vérifier le routage de l’application
Figure 4 - Routage de l’application
Etape 3 : classe HomeController
Exemple qu’on peut ajouter dans le contrôleur de la classe pour tester l’affichage :
[HandleError]
public class HomeController : Controller #1
{
public ActionResult Index() #2
{
ViewData["Message"] = "Welcome to ASP.NET MVC!";
return View();#3
}
public ActionResult About()
{
return View();#3
}
}
#1 Il hérite de Controller
#2 déclaration des méthodes d’action.
#3Retour de la vue Home
Etape 4 : Création des contrôleurs, des actions et des vues
1. Création d’un contrôleur : GuestBookController
Figure 5 - l'ajout d'un contrôleur
Figure 6 - Action par défaut générée
2. Création d’une vue
Figure 7 - Création d'une vue
On ajoute ce code dans l’index de la vue crée :
On ouvre le fichier /Content/Site.css et on ajoute ce block :
Figure 8 - Vue final
On ajoute une action dans le contrôleur, cette méthode permet de stocker les données du formulaire dans une variable de type dictionnaire (ViewData).
Figure 9 - Ajout d'une action dans le contrôleur
Le retour d’une vue « Thank you » pour afficher par la suite les données entrées dans la vue initiale.
Figure 10 - Page de vue Thank you
En exécution on aura ça :
Figure 11 - Page Index.aspx
Figure 12 - Le résultat est dans la vue Thank you
L’exemple précédent est fonctionnel mais il comporte des inconvénients :
· L’URL du formulaire est “hard-coded”, si on change sa structure, ça ne marche pas.
· On a parlé du MVC mais il nous manque l’utilisation du Modèle.
· L’utilisation de ViewData["foo"] utilise des chaînes magiques et repose sur le casting pour faire quelque chose significative avec les données.
· L’URL reste
· L'URL dit encore "Inscrivez-vous», même si nous avons rendu la vue ThankYou, c’est parce que nous ne sont pas redirigé vers une page de succès; nous avons simplement retourné une page. C’est le deuxième aspect négatif du site.
· Si vous actualisez cette page, il vous invite à soumettre à nouveau les données. Si l'utilisateur introduit les mêmes données, deux documents vont affichés une redondance de données introduites.
II. Amélioration de l’application
Etape 1 : utilisation de Html.BeginForm helper pour générer un formulaire
Etape 2 : Création d’un modèle vue pour l’application GuestBook
Etape 3 : Acceptation d'un objet complexe comme un paramètre d'action
Etape 4 : Changer la vue index en ViewPage<T>
Etape 5 : Fourniture de l'instance du modèle prévu à l'affichage
Etape 6 : Utilisattion de “strongly typed view helpers” à la place des chaines de caractère
Dans l’exemple précédent, on a relevé le problème de rafraichissement qui cause la duplication des entrées, donc dans ce formulaire, nous utilisant le Pattern « Post-Redirect-Get (PRG) pattern ».
Il consiste à :
1- Envoyer certaines données à une action.
2- Redirection de l’utilisateur à une action différente.
3- Le navigateur de l'utilisateur émet une requête GET pour la nouvelle action.
Parce que le navigateur a délivré un GET au moment de la dernière requête, une actualisation de ne pas nuire à tous. Il récupère simplement la page à nouveau.
Etape 7 : Implémenter le « Post-Redirect-Get »
Etape 8 : La vue « ThankYou » qui utilise un helper pour afficher l'objet du modèle
Figure 13 - Ajouter une vue « Thank You »
Et nous aurons le même résultat de début, sauf qu’ici on a utilsié un modèle et des html helpers pour faciliter les tâches.
