ASP.NET MVC2 - Le modèle et la vue fortement liée

Article prenant part à une série d’articles reliés à l’ASP.NET MVC :

ASP.NET MVC2 - Introduction

ASP.NET MVC2 - Votre première application

ASP.NET MVC2 - Le modèle et la vue fortement liée

Le modèle :

Pour expliquer la notion de modèle, je reprendrai l’exemple de Mr Steven Sanderson.

Voici le contexte :

Votre amis organise une soirée et voudrait que vous créiez un site qui permette aux invités de répondre via l’intermédiaire d’un formulaire envoyant un message électronique.

Cette application devra :

Afficher les informations concernant la soirée par une page Index.
Posséder un formulaire où l’invité peut entrer ses coordonnées et prévenir si il s’y rend ou pas.
Envoyer un email détaillé de ces invitations à l’organisateur.

Reprenons noter page créée précédemment (voir ASP.NET MVC2 - Votre première application) dans la vue index et rajoutons-y quelques informations :

Voici le résultat :

Voici donc notre vue incluant un lien, si nous cliquons sur celui-ci, nous recevons une erreur 404. Ceci est tout à fait normal vu que nous n’avons pas d’action portant ce nom dans ce controller.

Vous remarquez que contrairement à l’ASP.NET classique, le lien ne correspond pas à un fichier se trouvant sur le serveur mais à une configuration de votre sytème de routing . Celui-ci vous aidera à vous diriger vers une action comprise dans un controller.

Chaque action aura automatiquement sa propre URL. Vous n’avez donc pas besoin de créer une page ou une classe pour chaque lien.

En faisant un view source du code générer par la méthode action link, vous voyez que le résultat est un html propre :

<a href=”/Home/SEND”>Inscris-toi maintenant</a>

En effet, ActionLink est l’un des composants permettant la génération d’HTML à partir de la class « helper » html compris dans le framework ASP.NET MVC. C’est dans cette classe que vous trouverez les méthodes pour générer vos textbox, textarea, checkbox,…

NB : Vous remarquerez que la méthode ActionLink est surchargée et permet donc des comportements différents, je vous laisse découvrir cela par vous-même.

Nous verrons également que nous ne sommes pas obligé d’utiliser ces méthodes et que nous pourrions tout aussi bien utiliser du html écrit “à la main”. Afin d’avoir un apperçu des différents composants, je vous invite à explorer celui-ci via l’intellisense de Visual Studio. J’ai le présentement que vous allez vous servir de ce helper assez souvent dans les prochains mois.

Créons maintenant une action SEND dans notre controller et ajoutons-lui une vue.

Ajoutez cette vue SEND de la même manière que dans notre dernière article, Bouton-droit ajouter une vue.

Lancez l’application et regarder si la page blanche créée s’affiche correctement.

À ce stade, vous seriez tenté de continuer comme dans une application ASP.NET classique et créer un formulaire dans cette page via des contrôles ASP.NET.

C’est ce que nous allons faire mais avant cela attardons nous sur notre modèle.

En effet, le modèle est l’une des parties les plus importantes de notre application. En effet, si on y réfléchit, c’est celui-ci qui renfermera la connaissance que nous avons sur notre domaine. Le reste n’étant que des outils facilitant l’affichage et/ou à la manipulation de données. C’est dans notre modèle que la logique de notre situation transparaîtra. C’est lui qui doit refléter le monde réel, il est entièrement créé par vous et peut donc correspondre de manière très proche à la réalité. que vous vous êtes faites de votre domaine

Dans notre cas, notre domaine n’est pas très compliqué, ce qui aura pour effet la création d’un modèle simple.

Un simple objet encapsulant les coordonnées et un paramètre nous permettant de savoir si la personne assistera ou non à la soirée sera un modèle valable pour cette application.

Ajoutez un fichier ReponseVisiteur.cs dans notre modèle et ajoutez à cette classe les paramètres souhaités.

Seul particularité de cette classe, le paramètre WillAttend est de type booléen nullable part l’ajout du caractère ‘?’ directement après la déclaration du type de la variable. Ce qui paramétra la création d’une variable à trois états, true, false ou null.

Créons maintenant le formulaire pour la vue.

Si vous lancez cette application, vous remarquerez que lorsque vous cliquez sur le bouton submit, la page se recharge en perdant les informations entrées dans le formulaire. Ce comportement est tout à fait normal. En effet, l’action SEND a pris en charge votre requête car vous n’avez pas d’autre action dans votre controller capable d’interpréter un post de manière correcte.

Nous remarquons que ce comportement n’est pas tout à fait normal, en effet, l’action SEND de votre controller ne devrait être utilisé que pour une méthode de type GET, c’est-à-dire seulement pour afficher la vue et non pas pour interpréter une requête de type post.
Pour cela, ajoutons un attribut permettant à l’action de n’accepter que des requêtes de type GET. Faisons de même pour la méthode index de notre HomeController.

Relançons notre application et regardons ce qu’il se passe. Après avoir appuyé sur notre bouton submit. Nous recevons une page d’erreur 404.

Comportement normal, il n’y a maintenant plus d’action dans notre Controller capable de répondre à une requête de type “post” à l’url correspondante (Home/SEND).

Nous devons donc créer une nouvelle méthode afin de pourvoir interpréter cette requête. Celle-ci ne devra prendre en compte que des requêtes de type POST, elle devra prendre en paramètre un objet de type ReponseVisiteur (créé depuis notre formulaire de la page SEND) et à partir de ce même objet, devra exécuter de la logique et ensuite être retournée, par exemple, à une vue Thanks. Cette vue devra afficher un message différent suivant la réponse de l’invité.

Le Model Binding :

Grâce au Model Binding (composant d’ASP.NET MVC), les données entrantes sont automatiquement créées et utilisées en paramètre par les actions, ceci étant possible par une correspondance de paires clé/valeur entrantes avec le nom de la propriété du type désiré en NET.

Plus concrètement, ce binding, nous permettra d’éviter de devoir jouer avec des dictionnaires tels que Request.Form[] et Request.QueryString[]  aussi souvent qu’en webforms. En effet, comme les noms de nos contrôles se trouvant dans la page SEND.ASPX correspondent aux noms des propriétés de nos objets. Automatiquement, le framework nous fournira une instance de notre objet ResponseVisiteur avec n’importe quelle valeur entrée dans nos contrôles.

Revenons à nos moutons et retournons à nos deux actions afin d’illustrer ce comportement :

Nous remarquons qu’il est donc possible de passer un objet à une vue.
À noter que pour arriver à ce résultat, nous devons ajouter le namespace « using Kiwi.Web.Models » afin d’avoir un accès à nos modèles.

Vue fortement typée :

Si vous regardez attentivement l’action SEND devant interprétée une requête de type POST, nous passons à la vue “Thanks” un objet de type ReponseVisiteur. Pour que cette vue puisse interpréter cette objet, il faudra donc créer une vue dite fortement typée. En faisant cela, nous définissons le modèle de la vue. Nous pourrons alors depuis celle-ci accéder aux propriétés de cette objet.

Créez cette vue fortement typée. Pour cela, cliquez-droit sur le nom de votre action > add > View.

Nous arrivons sur cet écran :

Nous définissons donc le type ReponseVisiteur comme mode pour notre vue. Cliquez sur Add et une vue Thanks sera ajoutée à notre site.

Voici notre vue :

La partie soulignée en rouge est importante, en effet, nous voyons que notre vue héritée de la classe MVC.Viewpage est typée fortement par ResponseVisiteur.

Le point fort de ce typage est l’accessibilité aux paramètres de l’objet depuis notre vue.

Comme vous le remarquez, nous avons accès au propriété de la classe par Intellisense.

Essayons de nouveau d’envoyer notre formulaire en introduisant quelques valeurs (attention pas de validation pour le moment).

Voilà le résultat.

Premier constat : html propre, pas de viewstate. N’est ce pas génial ?

Ajoutons maintenant de la Validation :

N’oublions pas que cette validation concerne le modèle et non pas la vue. En effet, les validations reflètent généralement des règles du business. Et il sera, pour vous, plus facile de maintenir vos règles si celle-ci se trouvent à un seul et même endroit dans votre application. Autre avantage, en intégrant les règles dans votre modèle, vous êtes certains que l’intégrité de votre système reste respecté et ce quelque soit la vue ou le Controller qui est connecté avec ce modèle. Ceci est, selon moi, une manière plus robuste que les contrôles de validation d’ASP.NET de type <asp:XyzValidation>.

La manière de valider qui va suivre n’est pas la plus puissante et nous verrons plus tard les autres techniques de validation qui existent en ASP.NET MVC.

Pour cela, rendez-vous dans votre objet ReponseVisiteur et implémentez l’interface IDataErrorInfo.

Maintenant, retournons dans notre controller afin d’adapter notre action suivant le résultat de la validation.

Et pour la vue, nous rajoutons la méthode Helper HTML.ValidationSummary(), cette méthode permet d’afficher les messages d’erreurs contenu dans notre Modèle.

Grâce au binding du modèle qui « parse » les données entrantes, nous pouvons retournée la vue et si nous rencontrons une erreur, les contrôles seront réinitialisés avec les données qui avaient été introduites auparavant. Pourtant, nous sommes dans un contexte http « stateless ». Cela crée une apparence d’application « statfull », nous verrons ces mécanismes plus en profondeur plus tard.

Réessayons notre application :

Terminons l’application en rajoutant notre méthode permettant d’envoyer un mail :

Cette application utilise l’API SMTPCLient. Par défaut, SMTPClient cherche les paramètres concernant le serveur mail dans le Webconfig de votre site. Ajoutez ces lignes pour envoyer des mails :

Généralement, en développement, on préfère stocker les mails dans un répertoire plutôt que de polluer le destinataire, pour cela configurez votre webconfig de la manière suivante :

Je vous laisse le soin de configurer ceci et de tester cette application.

En conclusion :

Vous venez de créer une première vraie application ASP.NET MVC, vous avez maintenant appris à jongler avec les vues, le controller et le modèle. Vous savez maintenant lier une vue avec un modèle et vous avez également approché le concept de validation dans ASP.NET MVC.

Pour terminer regardons de plus prêt l’architecture ASP.NET MVC :

Dans cette architecture, les requêtes HTML de type request sont routées vers un controller, celui-ci travaille avec le modèle afin d’interpréter les données utilisateurs et mener à bien la requête. Le modèle représentant la logique du business et le Controller la logique de l’application (gestion de la session, authentification,…). Lorsqu’il faut retourner les données vers l’utilisateur, le controller prépare ces données pour la vue par l’entremise du « presentation model », le ViewData en ASP.NET MVC.

Le Controller n’étant pas lié à la vue, celui-ci est entièrement testable. Les vues, elles, sont de simples outils permettant d’afficher du HTML à partir de données se trouvant dans le viewdata. Elles permettent l’itération afin de générer des tableaux, des listes, elles ont la possibilité de cacher ou non une partie de page et bien d’autres comportements sont possibles. De manière générale, cette logique doit rester simple et ne peut avoir comme but que l’affichages de données et de formulaire. Vous ne penserez plus en terme de contrôle comme en ASP.NET classique mais en terme de requête request/response HTML.

Pour plus d’info concernant les différentes architectures du point de vue théorique, je vous renvoie vers le site de Mr Fowler : http://martinfowler.com/eaaDev/uiArchs.html

Au point de vue .NET :

Les controllers sont des classes ASP.NET MVC qui dérivent toutes de la classe Controller d’ASP.NET MVC. Chaque classe publique appelée « Action method » est automatiquement associée à une URL se trouvant dans le schéma d’URL que vous configurez. Ces actions exécutent les opérations et renvoient ensuite une réponse, par exemple, l’affichage d’une vue. Ce mécanisme d’entrée/sortie a été pensé dans le but d’être testable facilement, vous n’êtes donc pas couplé à un serveur Web en fonction.

Le framework supporte différent view engine. Par défaut, les vues sont de simple page webforms aspx,libérées du viewstate, du code-behind (pas de .cs) et du comportement des postbacks.

Concernant votre modèle, ASP.NET ne vous fournit pas de cannevas et vous êtes libre de créer vos objets dans la manière qui vous sierra le mieux. Concernant les aller/retour entre modèle et base de données, vous êtes encore une fois libre d’utiliser vos propres classes ou n’importe quel ORM fonctionnant en .NET. Par défaut, ASP.NET MVC créé un répertoire Model, vous pouvez l’utilisez mais libre à vous de créer une dll et d’utiliser celle-ci en modèle.

Vous remarquerez qu’ASP.NET MVC n’est pas tout à fait un MVC classique mais adapté au web et à l’ASP.NET.

Je pense que vous êtes maintenant prêt à passer dans le vif du sujet et construire une application réelle en utilisant ASP.NET MVC. J’espère vous avoir donné une bonne introduction via ces trois premiers articles. Dans mes prochains articles, nous approfondirons certains composants d’ASP.NET MVC et j’espère que nous arriverons à construire cette application ensemble dans une philosophie agile. J’attends de vous un retour afin de discuter des choix architecturaux au cours de ce périple. À bientôt !