Créer une application web en asp.net mvc 2

Créer une application web en ASP.NET MVC 2 Auteur : Iulia NAGY

Présentation de l’architecture ASP.NET MVC2

L’architecture ASP.NET MVC2 a été mise en place par Microsoft suite à un besoin récurant de testabilité, ajustabilité et un meilleur control au niveau des applications qui devient de plus en plus marquant.

La technologie est basée sur le design pattern Modèle-Vue-Contrôleur (MVC) qui propose un découplage des couches au niveau de l’application (le modèle, la vue et le contrôleur) et ainsi un meilleur contrôle.

La plateforme MVC2 permet de combiner la flexibilité fournie par le MVC avec les avantages de l’ASP.NET.

28/11/2011 Groupe NOVENCIA - 25 Rue de Maubeuge 75009 PARIS - Tél. : 01 44 63 53 13 - Fax : 01 44 63 53 14 - www.novencia.com - [email protected] 2

Fonctionnement de l’architecture ASP.NET MVC2 Contrairement à ce qu’on peut être amené à croire, l’architecture du MVC2 ne suit pas du tout le même fonctionnement qu’ASP.NET: les événements du cycle de la page (Init, Load, Render etc) n’existent plus, en occurrence le degré d’automatisation des requêtes est moindre. Ainsi plus de flexibilité s’offre à l’utilisateur, sachant qu’en revanche une très bonne compréhension de la technologie est nécessaire. Un exemple concret de la différence entre ces deux technologies est que certains comportements ASP n’existent plus: les notions de PostBack et ViewState sont absentes, l’utilisateur étant amené à gérer la persistance des données par des nouveaux mécanismes ( URLs et POSTing form data). La plupart des composants graphiques restent quand même inchangés (on parle de master page, fiches de style etc.) Le MVC2 repose sur un moteur de routage au niveau des requêtes, et sur des contrôleurs qui permettent d’implémenter le comportement attendu en réponse à ces requêtes.



Figure 1 Architecture ASP.NET MVC2

Comme un schéma est souvent plus parlant qu’une longue phrase voici en une image comment le MVC2 fonctionne:

Tout d’abord l’utilisateur cherche à obtenir une page (un HTTP request est émis).

Le contrôleur prend en charge cette requête en cherchant les données nécessaires au niveau du model de données (NomModel) et ensuite il remplit la page à rendre (NomView) avec les données nécessaires. La page demandée est ensuite rendue à l’utilisateur (par l’intermédiaire d’un HTTP Response) du côté de la vue.

Cette technologie repose principalement sur le principe de routage (la plupart des éléments nécessaires se trouvent dans l’espace de nom System.Web.Route).

Avant d’expliquer tout le fonctionnement du MVC2 cela serait plus sympathique d’avoir un petit projet sur le coude non ? Allez, on y va !


Création d’un premier projet MVC2

Dans Visual studio nous ouvrons la fenêtre pour créer un nouveau projet


Avant la finalisation de la création de votre projet, VS vous demandera si vous souhaitez créer des tests unitaires (un des gros avantages de ce Framework). Pour rester basique dans ce tutorial nous avons choisi de ne pas les intégrer


Et voici l’architecture par défaut de notre nouveau projet :


Nous remarquerons facilement l’existence de 4 nouveaux dossiers dans ce projet qu’on n’avait guerre vue en ASP.NET : Controllers, Models, Views et Content. Si vous ne l’avez déjà remarqué, trois de ces dossiers correspondzent aux 3 composants de l’architecture MVC (voir figure 1) : contrôleurs, modèles et vues et le 4eme (Content) est utilisé pour stocker des fichiers statiques tel les images, feuilles de style ou bien des pages html statiques.

La vue La vue assure la manière dont les données sont présentées à l’utilisateur. Cela est fait à travers des pages web (.aspx) et user controls (.ascx).

Ces composants ont une fonction purement graphique, toute la logique étant gérée par le contrôleur.


Par défaut 3 dossiers sont générés lors de la création du projet : Account, Home et Shared. Account contient toutes les vues relatives à l’authentification de l’utilisateur. Home contient la page d’accueil par défaut et le Dossier Shared contient des vues qui sont partagées entre des contrôleurs multiples tels la page d’erreur ou la Master Page. Nous pouvons également remarquer que ces pages ont étés dépourvues de tout code behind (comme nous l’avons précisée plus haut ils ont une fonction purement graphique).

Le modèle

Le modèle contient toutes les données nécessaires au fonctionnement de l’application. Il assure également la logique métier et la validation de la data. Cette couche contient toutes les méthodes CRUD vers la base de données, et est souvent générée avec l’aide d’un ORM ( Entity Framework – voir l’article « Premiers pas avec Entity Framework 4.0 » ou NHibernate).

Nous pouvons également opter pour une implémentation Linq to SQL.


Par défaut Visual Studio génère le modèle qui s’occupe de la gestion des comptes utilisateurs. En jetant un œil sur le fichier généré nous pouvons facilement remarquer que le fichier AccountModels contient 3 principales régions : Modeles, Services et Validation (voir figure).


Le contrôleur

Les classes contenues dans le contrôleur sont chargées de gérer l’interaction avec l’utilisateur et également faire la liaison entre le modèle et la vue.

Ainsi les requêtes HTTP correspondant aux actions de l’utilisateur sont redirigées vers les contrôleurs correspondants.

Une fois le bon contrôleur trouvé celui-ci doit répondre à la requête de l’utilisateur en appelant le modèle pour remplir les données et ensuite en afficher la vue correspondante.


Par défaut Visual Studio génêre deux contrôleurs: Account (qui est chargé des actions qui concernent l’authentification des utilisateurs) et Home (qui est chargé des actions venant depuis la page d’accueil).

La structure de la classe AccountControler est la suivante :


L’autre contrôleur, Home, a la structure suivante:


Nous remarquerons l’existence d’une méthode Index qui retourne la vue en ajoutant un message à afficher et une méthode About qui retournera la vue About. Les méthodes contenues dans les contrôleurs sont souvent appellées des méthodes d’action (ActionMethod en anglais). Nous remarquerons d’ailleurs que chaque méthode du contrôleur renvoie comme réponse un ActionResult. Nous allons dédier le chapitre suivant à l’ActionResult car celui-ci constitue une partie très importante dans le Framework

Comprendre l’utilité des ActionResult et le principe de routage.

Comme nous l’avons déjà vu, l’ActionResult est le type de retour de n’importe quelle méthode d’action. Ces méthodes peuvent retourner des modèles qui alimentent les vues, des filesteams, rediriger vers d’autre contrôleurs etc.

La têche du contrôleur est justement de faire le lien entre différentes entités, se comportant comme une espèce de gendarme qui s’assure que tout fonctionne correctement.

Les méthodes d’actions sont fortement liées au système de routage caractéristique des applications MVC. La liaison entre ces composants est établie grâce aux différents routing patterns (patterns de routage).

Ces routing patters sont définis dans le fichier global.asax.cs. Leurs buts est de connecter des requêtes HTTP avec les contrôleurs et les méthodes d’action.

Ainsi quand une requête HTTP rentre dans le système de routage, le routing pattern décide quel contrôleur doit être chargé pour quel vue.


Dans global.asax.cs nous trouverons le routing pattern par défaut - {controller}/{action}/{id} :


Afin de mieux comprendre le système de routage nous allons prendre chaque composant à part : • {controller} - cette partie fait la liaison entre la première partie de l’url et le nom de la classe contrôleur correspondante. Ainsi une classe nommée ArticlesController va référencer l’URL qui commence par /Articles. Nous remarquerons que la désignation du Controller a été enlevé (le but c’est de rendre la lecture des URL simple pour les utilisateurs).

{action} – l’action fait référence aux méthodes qui se trouvent à l’intérieur des contrôleurs – les méthodes d’action.

Ainsi les URL /Article/Create et Article/Details vont être respectivement redirigées vers les méthodes ArticlesController.Create(), ArticlesController.Details() pour être résolus.

Ceux-ci redirigent vers des méthodes sans paramètres, car le composant suivant s’occupe de la gestion des identifiants.

{id} – comme le nom l’indique très bien, le paramètre « id » fait la liaison vers un identifiant. Plus exactement il s’agit d’un identifiant qui est passé en paramètre à une méthode d’action.

Par exemple URL /Articles/Edit/1 va permettre l’accès en modification vers l’article qui a l’identifiant 1. Cet article est ramené depuis le modèle par l’intermédiaire de la méthode ArticlesController.Edit(int id) du contrôleur.

Cette requête est normalement utilisé pour ramener un seul objet depuis la base de données en fonction de son id.


Exécution de l’application

Voici ce qui est retourne lors de l’exécution du projet :

Pour la page Home – le texte que nous voyons apparaître c’est bien le texte que nous avons paramétrée a travers le View[«Message »].


Pour la page About (A propos de en français)

Nous voyons facilement dans la barre de navigation que le principe de routage est bien suivi :

Nous sommes présent dans « /Home/About » – en l’occurrence pour afficher la page le contrôleur HomeController a été appellé et à l’intérieur de celui-ci la méthode HomeController.About() a été employé.

Conclusion

Cet article n’est qu’une très brève introduction au Framework ASP.NET MVC2. Il vous permettra de comprendre la logique qui est employé derrière et de pouvoir approfondir et vous lancer dans le développement de sites par la suite !


Documents

Créer une application web en asp.net mvc 2