ASP.NET MVC
Avec ASP.NET MVC, Microsoft nous propose un nouveau framework pour créer des applications web, en complément des WebForms qui existent depuis plusieurs années déjà.
Ce framework nous propose une nouvelle façon de créer nos projets web, basée sur le pattern Modèle-Vue-Contrôleur qui, grâce à une séparation correcte des couches, devrait permettre un codage plus propre. Nous allons voir dans cet article les bases à connaître pour débuter avec ASP.NET MVC.
Pour démarrer, voici les quelques liens indispensables.
Site officiel : http://www.asp.net/mvc/
Page codeplex : http://aspnet.codeplex.com/Wiki/View.aspx?title=MVC
ASP.NET MVC est disponible en version finale sous forme d’add-on pour Visual Studio 2008 SP1, disponible à l’adresse suivante :
http://www.microsoft.com/downloads/details.aspx?FamilyID=53289097-73ce-43bf-b6a6-35e00103cb4b&displaylang=en
Si vous n’avez pas Visual Studio, vous pouvez utilisez la version gratuite : Visual Web Developer Express : http://www.microsoft.com/express/vwd/
Créer un nouveau projet MVC
La création d’un nouveau projet propose une structure de dossiers destinée à implanter correctement le pattern MVC.
· Content contient le contenu statique du site : fichiers css, images
· Controllers contient les contrôleurs
· Models contient les modèles (classes .net, par exemple avec LinqToSql). On préfèrera ne pas utiliser ce dossier pour placer le modèle dans un projet séparé.
· Scripts contient les fichiers JavaScript. Par défaut, contient la librairie Ajax de Microsoft, ainsi que jQuery.
· Views contient les vues : des fichiers aspx et ascx appelés par les différents contrôleurs.
Ce nouveau projet contient un site d’exemple avec quelques pages et une gestion des utilisateurs, qui peut servir de base à un nouveau projet. Il suffit de faire Ctrl+F5 pour le voir tourner :
Routing
Il est important de comprendre le fonctionnement du routage d’URL. Les développeurs WebForms ont l’habitude d’avoir une URL qui corresponde au chemin d’un fichier aspx. Avec MVC, ce n’est plus le cas : une URL doit appeler une action dans un contrôleur. Il a donc fallu définir de quelle manière trouver l’action associée à une URL. Pour cela, le module de routing a été créé, le routage des URL est défini dans le fichier Global.asax :
public static void RegisterRoutes(RouteCollection routes)
{
routes.IgnoreRoute("{resource}.axd/{*pathInfo}");
routes.MapRoute(
"Default",
"{controller}/{action}/{id}",
new { controller = "Home", action = "Index", id = "" }
);
}
On peut ajouter autant de nouvelles routes qu’on le souhaite en appelant routes.MapRoute avec les paramètres :
· name : nom de la route (doit être unique)
· url : définit le format de l’url. Peut contenir (mais pas obligatoirement) le nom du contrôleur et de l’action à appeler. On peut aussi définir les différents paramètres dont l’action a besoin.
· defaults : les valeurs par défaut dans le cas où l’url ne contient pas toutes les valeurs.
Exemple : l’url /Pages/Details/5 va appeler l’action « Details » dans le contrôleur « PagesController » et lui faire passer le paramètre id avec la valeur 5. Si un utilisateur va sur l’url /Pages/, il va appeler le contrôleur « PagesController », et l’action n’étant pas définir dans l’url, l’action par défaut « Index » va être appelée.
L’intérêt de ce module de Routing, outre le fait de savoir à quoi doit correspondre une URL, est qu’il permet d’avoir des URL propres. Cela a plusieurs avantages :
· Le référencement : les moteurs de recherche se basent souvent sur les URL pour indexer le contenu de votre site. En effet, pour les bots qui parcourent votre site, « Page.aspx?id=1 » et « Page.aspx?id=2 » sont une seule et même page, « Page.aspx » avec un paramètre. Avec ce module de routing, on aura des URL de type « /Page/1 » et « /Page/2 » qui seront considérées comme 2 pages distinctes.
· L’expérience utilisateur : une URL bien structurée permettra à vos utilisateurs de voir d’un coup d’œil dans quelles sections/sous-sections il se trouve sur votre site (une sorte de fil d’Ariane intuitif). Et grâce à la gestion des valeurs par défaut, il pourra en supprimant la fin de l’url remonter aux sections supérieures.
Là où on était obligé d’utiliser des modules de réécriture d’URL pour arriver à ce but, on a maintenant une gestion des URL au cœur de notre site, ce qui en simplifie l’utilisation en supprimant une surcouche.
Les contrôleurs
La version 1 RTM a apporté un éditeur qui aide à la création de nouveaux éléments dans le projet. On commence par créer un contrôleur :
Le nom du contrôleur doit forcément se terminer par Controller. On a la possibilité de demander à l’éditeur la création d’actions par défaut.
Une fois créé, le contrôleur doit contenir des actions. Chaque action est une fonction qui retourne un résultat de type ActionResult.
public ActionResult Index()
{
return View();
}
Les actions peuvent aussi recevoir directement les paramètres venant de l’URL.
public ActionResult Details(int id)
{
return View();
}
Les ActionResult peuvent être de plusieurs types :
· L’appel d’une vue :
return View();
Retourne une vue au navigateur. Si rien n’est spécifié, la vue retournée est celle qui a le même nom que l’action.
Il est possible de définir quelle vue retourner au navigateur, et de faire passer des données à afficher dans la vue (voir Vues)
· Une redirection. Il existe plusieurs types de redirection :
o return Redirect("url");
Fais une redirection vers une url
o return RedirectToAction("Index");
Redirige vers une autre action, avec la possibilité de spécifier un autre contrôleur et de faire passer des paramètres.
· Envoi de contenu : on peut envoyer directement du contenu au client sans passer par une vue, en envoyant directement un fichier, ou en envoyant directement une chaine de caractères :
o return Content("<div>exemple</div>");
o return File("fichier.doc", "application/msword");
Il existe d’autres ActionResult, et il est aussi possible de créer ses propres ActionResult qui correspondraient à un besoin particulier.
Les vues
Les vues sont des fichiers aspx qui contiennent le code HTML à renvoyer au navigateur, qui permettent d’afficher les données passées par le contrôleur. Tout comme en WebForm, on peut définir des MasterPage, et afficher dans nos vues des vues partielles, équivalent MVC des UserControl.
Le dossier « Views » de notre projet contient plusieurs dossiers, un par contrôleur, ainsi qu’un dossier « Shared » pour les vues partagées par plusieurs contrôleurs.
Le contrôleur peut spécifier le nom de la vue à appeler. Lorsque le contrôleur appelle une vue sans spécifier le nom, la vue cherchée est le nom de l’action.
Lorsqu’une vue est appelée, MVC va chercher un fichier aspx ou ascx dans le dossier des vues du contrôleur, et s’il ne trouve pas, va chercher dans le dossier « Shared ».
Création d'une vue depuis le contrôleur
L’éditeur MVC intégré à Visual Studio permet de créer facilement une vue associée à une action, en affichant le menu contextuel dans l’action :
L’interface permets de personnaliser sa vue :
· View name : le nom de la vue. Par défaut le nom est le même que celui de l’action.
· Partial view : crée une vue partielle, au lieu d’une page complète
· Strongly-typed view : crée une vue fortement typée, afin de définir le type des données qui sont passées à la vue. Si on choisit cette option, on peut choisir de créer la vue avec un template prédéfini pour l’affichage, la création ou la modification des données.
· Master page : tout comme en WebForm, on peut utiliser une MasterPage sur notre site.
Passage de données du contrôleur à la vue
Afin de faire passer les données du contrôleur à la vue, on a deux façons de faire :
· Le ViewDataDictionary : le contrôleur tout comme la vue a accès à une variable ViewData, qui est en fait un dictionnaire clé/valeur, dans lequel on peut stocker toutes les données pour que la vue les affiche directement.
· Le Model (fortement typé ou non) : le contrôleur peut faire passer une variable à l’appel de la vue. Si on a défini une vue fortement typée, la variable passée doit être du type de la vue. La page aspx a ainsi accès à cette variable en connaissant son type.
Exemple :
public ActionResult Details(int id)
{
Element elmt = Context.GetElementById(id);
if (elmt == null)
return View("ElementNotFound");
ViewData["PageTitle"] = elmt.Name;
return View("Details", elmt);
}
Ici, on récupère un élément à partir de son identifiant. Si l’élément n’est pas trouvé, on charge une vue « ElementNotFound », à laquelle aucune donnée n’est passée.
Si l’élément est trouvé, on va appeler la vue « Details » (la vue étant la vue par défaut de notre action, on n’est pas obligé de mettre son nom à l’appel de la vue, on aurait pu se contenter d’écrire return View(e);), à laquelle on a fait passer plusieurs données : le titre, par l’intermédiaire du dictionnaire ViewData, ainsi que l’élément « elmt » à l’appel de la vue.
Pour afficher nos données, on récupèrera ces variables directement dans notre page aspx :
<asp:Content ID="Content1" ContentPlaceHolderID="TitleContent" runat="server">
Details for the element : <%= ViewData["PageTitle"] %>
</asp:Content>
<asp:Content ID="Content2" ContentPlaceHolderID="MainContent" runat="server">
<h2>Details</h2>
<fieldset>
<legend>Fields</legend>
<p>
Name:
<%= Html.Encode(Model.Name) %>
</p>
<p>
Value1:
<%= Html.Encode(Model.Value1) %>
</p>
<p>
Value2:
<%= Html.Encode(Model.Value2) %>
</p>
</fieldset>
</asp:Content>
Création de liens
Pour faire des liens vers d’autres actions dans nos pages, on a un Html helper qui va nous permettre de créer automatiquement nos liens en fonction d’un nom de contrôleur et d’action. Il suffit d’appeler la méthode Html.ActionLink :
Les paramètres à passer sont les suivants :
· linkText : le texte du lien
· actionName : le nom de l’action à appeler
· controllerName : le nom du contrôleur à appeler. S’il n’est pas défini, l’action va être cherchée dans le contrôleur de la page courante.
· routeValues : les paramètres à passer à l’action, définis dans un type anonyme. Les paramètres sont récupérés par réflexion et passés à l’action du contrôleur.
· htmlAttributes : une liste d’attributs Html à ajouter au lien.
Actions faites par l’utilisateur
Jusqu’à présent, nous avons uniquement vu comment envoyer des données du serveur vers le client, mais pas comment l’utilisateur peut interagir avec votre site. Avec MVC, les postbacks n’existent plus, on revient aux sources du protocole http avec des formulaires html et des requêtes Post.
Les requêtes GET/POST
Faisons un rappel rapide sur les méthodes http ; les deux qui nous intéressent sont le GET et le POST.
La méthode GET sert à demander une ressource au serveur web. Il s’agit uniquement de l’appel d’une URL qui renvoie une réponse, une requête GET ne doit pas avoir d’effet sur le serveur.
Au contraire, la méthode POST est utilisée pour que le client envoie des données au serveur, c’est cette méthode qu’il faudra utiliser si on veut qu’un utilisateur ajoute ou modifie des données sur le site.
La différentiation de ces deux types de requêtes est importante. Si en théorie rien n’empêche l’utilisation d’une requête GET pour mettre à jour des données (ou d’un POST pour uniquement lire des données, comme c’est d’ailleurs le cas lorsqu’en asp.net on utilise la pagination par défaut des GridView), cela peut avoir des impacts négatifs sur le site :
· Généralement les robots se contentent de suivre tous les liens d’un site web, mais sans valider de formulaire (je parle ici des bots légitimes, par exemple ceux utilisés par Google pour indexer les sites web). Si on utilise une requête GET pour mettre à jour des données, les robots risquent de passer par ces liens, et donc de modifier vos données. Le problème est le même si l’un de vos utilisateurs mets une page en favori : il faut absolument que le lien pointe vers une page de votre site en lecture seule, et pas vers une page qui modifie des données.
· Pour le POST, on a le problème inverse : ici les bots ne verront pas vos pages. Si vous comptez sur Google pour indexer votre site web, vous lui masquez ainsi une partie de votre site, ce qui aura un impact négatif sur le référencement.
C’est donc cette différence entre le GET et le POST qu’on va utiliser avec ASP.NET MVC pour pouvoir proposer aux utilisateurs du site d’envoyer des informations : les actions par défaut répondront aux requêtes de type GET, et lorsqu’on en aura besoin on définira certaines actions qui répondront aux requêtes de type POST.
Principe des intéractions avec l’utilisateur
On va prendre un exemple classique d’un blog, où un utilisateur veut ajouter un article. Le blogueur va se retrouver sur une page où il pourra écrire son article, puis lorsqu’il validera une requête sera faite au serveur qui enregistrera l’article.
Dans cet exemple, on va avoir droit à une requête GET sur l’action « Create ». En effet, cette première requête renvoie le formulaire d’ajout d’article, et n’a aucun effet sur le serveur.
Lorsque l’utilisateur valide l’article, cette fois il envoie les données au serveur, c’est donc un POST qui est fait sur l’action « Create ».
Nous aurons donc dans notre contrôleur deux actions Create, l’une qui reçoit une requête GET, l’autre qui reçoit une requête POST ainsi que les informations envoyées par l’utilisateur. Dans notre code, ça se présentera comme ça :
On a une première action « Create » qui se contente de renvoyer sur la vue de création d’article
public ActionResult Create()
{
return View();
}
Dans la vue, on a un formulaire dans lequel l’utilisateur pourra écrire son article. On utilise ici le HtmlHelper, qui nous a déjà servi pour faire des liens, pour créer le formulaire :
<% using (Html.BeginForm())
{%>
<%= Html.TextBox("Title") %><br />
<%= Html.TextArea("Content") %>
<input type="submit" value="Valider" />
<% } %>
Html.BeginForm() permet de créer notre formulaire Html. Le fait d’utiliser le using permet de repérer le début et la fin du formulaire : le </form> sera positionné à l’endroit où se trouve l’accolade fermante du using.
Lorsqu’on clique sur le bouton submit, le formulaire envoie une requête POST à l’action « Create ». Cette fois, ce n’est pas la même action qui doit être appelée que lorsqu’on a fait un GET, on a donc une nouvelle action, qui n’acceptera que les requêtes POST :
[AcceptVerbs(HttpVerbs.Post)]
public ActionResult Create(Article article)
{
try
{
Context.SaveArticle(article);
return RedirectToAction("Details", new { id = article.Id });
}
catch
{
return View();
}
}
Cette méthode reçoit un objet de type Article en paramètre, cet objet a été créé par MVC, à partir des données du formulaire, dont les noms doivent correspondre aux propriétés de la classe Article.
Conclusion
Nous avons fait un tour d’horizon dans cet article des fonctionnalités de base d’ASP.NET MVC 1.0. Bien que les fonctionnalités avancées n’aient pas été abordées, vous pouvez d’ores et déjà vous lancer dans la conception d’un nouveau site web correctement structuré selon le pattern Modèle-Vue-Contrôleur.