Introduction à MVC et changement d’objectif – MVC 4 Web Application Tutoriel – Deuxième Partie – Etape 1 –

Dans cette introduction à MVC, nous allons examiner ce qu’est ce fameux “pattern”, mais tout d’abord quelques explications sur ce changement d’objectif.  Lors du lancement de ce tutorial, je n’avais qu’une très vague idée sur le genre d’application que je souhaitais réaliser. L’idée du “Challenge Personnel” me semblait intéressante, mais après réflexion ne me semble pas vraiment utile. J’ai décidé de partir sur une idée qui me semble beaucoup plus générique, pouvant être utile potentiellement a des milliers de personnes, et qui, d’après mes recherches, n’a pas véritablement d’équivalent aujourd’hui.

Je ne veux pas dévoiler tout de suite de quoi il s’agit, cela sera fait lors du démarrage effectif du projet et de la conception de la base de données. Aujourd’hui je peux simplement dire qu’il s’agira bien d’une application réelle, originale, gratuite bien sûr, utilisant une base de données, les technologies récentes avec HML 5, CCS 3, JQuery, etc. Le but final étant bien de réaliser une application Web, déployée et accessible par tout internaute, en espérant avoir mis en place un outil utile et ayant du succès auprès de ses utilisateurs.

Bien sûr les problèmes à résoudre seront directement liés à la mission de cette application particulière, mais en même temps les techniques utilisées devraient être suffisamment génériques pour servir d’exemple dans de nombreuses autres applications ASP.NET MVC.

La méthodologie utilisée s’approchera autant que possibles des méthodes SCRUM, c’est à dire que chaque itération du développement (et donc du tutorial) devra résulter en une fonction utilisable, c’est à dire qu’à la fin de chaque étape nous aurons “quelque chose” qui fonctionne, sans pour autant être nécessairement complètement fini.

Les sources et la totalité du projet seront disponibles pour tout le monde sur Git Hub, il sera ainsi facile de suivre l’évolution et d’y participer.

Cela étant dit, retournons à nos moutons, en l’occurrence MVC…

L’Architecture Modèle – Vue – Contrôleur

L’idée principale derrière MVC est de faciliter l’isolation des différentes partie de l’interface utilisateur de l’application, terme connu en anglais sous le sigle “SoC”, pour “Separation of Concerns”. Il s’agit de faire en sorte que les différents composants soient aussi indépendants que possible les uns des autres, ce qui a de nombreux avantages:

  • Développement: Comme les composants individuels sont conçu de manière à ne pas dépendre directement des autres, il est plus facile de les développer isolement. Cela facilite aussi leur remplacement, ou substitution, en éliminant les complications qui surviennent lorsque la modification d’un composant affecte le fonctionnement des autres
  • Capacité de Tester: De la même manière, la capacité de découpler les composants va faciliter la création de tests. Par exemple, il devient possible de remplacer la requête vers une base de données par une fonction retournant simplement une chaine statique, pour tester une partie de l’application. Cette facilité dans la création de tests est très précieuse au fil du temps, pour vérifier que la modification de certaines parties du système n’en affecte pas d’autres. Nous aurons l’occasion de revenir sur les tests tout au long de ce projet.
  • Maintenance: La encore, l’isolation des composants signifie aussi l’élimination (presque) totale d’effets de bord, et surtout le fait qu’un changement a de très grandes chances de ne nécessiter la modification que d’un seul des composants, éliminant de fait la nécessité d’une cascade de changements pour ajouter une fonctionnalité.

Pour être clair, le pattern MVC affecte uniquement (comme indiqué plus haut) l’INTERFACE UTILISATEUR, et plus généralement la structure globale de l’application. Dans une application réelle évoluée, ce ne sera pas le seul pattern utilisé, et il faut considérer chacun des composants de manière assez souple et non restrictive. Par exemple il est tout à fait possible d’avoir à développer une application MVC dans laquelle le modèle n’est pas en lien direct avec une base de données, mais avec des web services qui retournent des données. Cela n’empêche qu’il s’agira bien d’une application utilisant le pattern MVC.

Le Modèle

Plus souvent, les modèles. Il s’agit d’un ensemble de classes représentant le domaine de votre application. Le plus souvent il s’agit d’encapsuler dans des objets les données stockées dans une base de données ainsi que le code nécessaire pour manipuler ces données et renforcer les règles spécifiques au domaine (métier) de l’application. Le plus souvent cela implique une couche d’accès aux données (DAL, Data Access layer) utilisant un outil comme Entity Framework où NHibernate, combinée avec du code contenant la logique spécifique au domaine de l’application.

La Vue

Son travail est de transformer le modèle en sa représentation visuelle. Pour une application web  cela veut dire générer le code HTML qui sera interprété par le navigateur de l’utilisateur. C’est aussi dans la vue que se trouvera le code JavaScript. Suivant les principes d’isolation “SoC”, la vue doit servir exclusivement à la visualisation des données et à l’interface utilisateur, et ne contenir aucune logique liée au domaine d’application.

Le Contrôleur

C’est le chef d’orchestre! Il contrôle la logique de l’application, reçoit les demandes utilisateurs de la vue, les transmet au modèle, effectue certaines actions en relation avec le modèle, et retourne le résultat à la vue.

Voyons tout de suite comment ces éléments s’articulent ensemble dans une première application MVC basique.

Première Application MVC 4

Dans Visual Studio, nouveau projet, web, MVC4 Application “MyFirstMVC4App”, puis sélectionnez le Template “basic” avec Razor comme View Engine. Dans l’explorateur de solutions, vous devriez avoir quelque chose comme dans la copie d’écran ci-joint:2013-10-28 17_36_59-MyFirstMVC4App - Microsoft Visual Studio

Même pour l’application “basique”, le Template MVC de Visual Studio a généré tout une série de répertoires, certains (Scripts, par exemple) contenant une liste impressionnante de fichiers. MVC repose sur le principe de “convention au lieu de configuration”, et les répertoires générés correspondent à cela.

Vous voyez notamment un répertoire Controllers, un répertoire Models, et un répertoire Views, mais ceux-ci sont vides (Ce n’est pas tout à fait vrai pour Views, mais nous allons y revenir).

Le répertoire Content est destiné aux fichiers css et aux images qui vont éventuellement avec, et il contient déjà un thème de base qui peut nous permettre de démarrer. Le répertoire Scripts quant à lui contient les scripts et librairies JavaScript.

Si nous lançons tout de suite l’application pour voir ce qui se passe avec CTRL- F5, nous n’obtenons aucune erreur de compilation, il s’agit bien d’une application valide et correctement structurée, mais à l’exécution, nous obtenons une belle erreur HTTP 404, ressource introuvable! Comme déjà dit, malgré les apparences, notre application est vide, d’ou cette erreur.

Pour ceux qui ont déjà créé des sites avec ASP.NET où un autre système, il pourrait sembler évident qu’il faille créer un fichier Index.aspx, où Index.html, pour résoudre le problème. Ce n’est pourtant pas la bonne méthode avec MVC.

Ce dont nous avons besoin, c’est d’un contrôleur. Rien ne fonctionne sans le chef d’orchestre. Et pas n’importe quel contrôleur. Toujours pour les mêmes raisons de convention, notre contrôleur principal, qui sera trouvé sans indiquer quoi que ce soit après l’URL, et correspond donc au fameux Index.html, doit s’appeler “HomeController”, et la méthode de ce contrôleur doit s’appeler “Index”. Nous découvrirons plus tard pourquoi, et comment changer cela si nécessaire, mais pour l’instant occupons-nous simplement  de faire en sorte que notre première application fonctionne sans erreurs, avant de lui ajouter quelques fonctionnalités.

Contrôleur

Pour créer notre premier contrôleur, faisons un clic droit dans solution explorer, sélectionnons “Add” dans le menu déroulant, et dans le sous-menu “Controller”: 2013-10-28 18_08_57-

Nommez-le “HomeController”, et dans les options de scaffolding, sélectionnez le template Empty MVC Controller. Voici le code généré pour vous:

Vue

Le mot View devrait être en rouge, IntelliSense nous indique qu’il ne trouve pas la vue correspondante. Si vous faites un clic droit sur ce mot, le menu déroulant va vous proposer comme première option, tout en haut, de créer la vue. Le dialogue qui suit comporte déjà le nom de la vue et les options correctes, il suffit de l’accepter. La vue générée ne comporte que le mot “Index”, c’est tout.

Si nous lançons à nouveau l’application, nous n’avons cette fois plus d’erreur, et la page affiche le mot “Index”. Si vous retournez voir le code du contrôleur, le mot View n’est plus en rouge. On ne peut pas dire que cette application fasse grand-chose, mais elle comporte déjà toute la structure nécessaire à une application plus complexe.

Modèle

Jusqu’à présent nous avons un Contrôleur et une Vue, mais pas de Modèle. Pour cette première application très simple qui ne nous sert qu’à mieux comprendre comment les éléments MVC s’imbriquent entre eux, nous allons créer un modèle simplissime, une seule propriété dans une classe:

Nous modifions le contrôleur pour instancier cette classe, et donner une valeur à la propriété dans la méthode index, et nous passons en paramètre l’instance du modèle à la vue:

La vue a besoin de connaitre le type de l’objet qu’elle reçoit en paramètre, ce que nous lui indiquons avec @model. On appelle cela une vue “fortement typée” (strongly typed).

Conclusion de cette première étape de la seconde partie

Nous avons réalisé une application MVC fonctionnelle, démontrant de manière super simplifiée l’articulation des éléments Modèle, Vue, Contrôleur. Vous pouvez constater que le “loose coupling” est bien présent. il est facile d’ajouter des propriétés au “DummyModel” sans perturber le fonctionnement de l’application. Vous pouvez modifier la vue pour en améliorer la présentation sans que cela ait de conséquences sur le code.

Si vous avez suivi notre première partie concernant HTML, vous avez constaté que notre vue est très incomplète. Il n’y a pas d’élément <HEAD>, pas plus que d’élément <BODY>, pourtant, si vous avez la curiosité d’aller regarder le code source généré, dans votre navigateur, ces éléments sont bien présents. Cela provient de l’utilisation de la vue _Layout.cshtml, qui se trouve dans le sous-répertoire Shared de Views. Nous examinerons comment cela fonctionne et détermine la présentation de l’ensemble de notre site dans la deuxième étape de cette série.

Le code de cette première application est assez simple pour que vous puissiez facilement le reproduire vous-même, aussi je ne pense pas nécessaire de la partager sur GitHub.

Si vous souhaitez être mis au courant de la parution d’un nouveau billet sur le site, abonnez-vous aux mises à jour par email, en cliquant dans la colonne de droite.

Faites part de vos retours, remarques, idées et commentaires ci-dessous.

This work is licensed under a Creative Commons license.

A bientôt!

Publié dans ASP.NET MVC 4.0, Tutoriel

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *

*

Lettre d’information

Recherche sur le Site

Recherche personnalisée