Qu'est-ce que l'architecture MVC ?
Nous avons vu ensemble les principes SOLID, mais avant de les analyser plus en détail, vous devez savoir comment organiser votre code de façon à pouvoir les appliquer facilement. Heureusement la solution est là. L'architecture MVC !
Il s'agit en réalité d'une approche d'architecture logicielle. Elle scinde les responsabilités du système en trois parties distinctes :
Le modèle qui contient les informations relatives à l'état du système ;
La vue qui présente les informations du modèle à l'utilisateur ;
Le contrôleur qui veille à ce que les demandes de l'utilisateur soient correctement exécutées, en modifiant les objets du modèle et en mettant à jour la vue.
Pourquoi est-il recommandé d'utiliser l'architecture MVC ?
Avant le lancement d'ASP.NET MVC par Microsoft en 2009, les développeurs s'appuyaient sur des formulaires Web pour créer des applications .NET. Ces formulaires Web reposaient sur des pages code-behind contenant des fonctions pour chaque événement de la page appelées contrôles serveur.
Autrement dit, une page Web constituait l'interface utilisateur, et une classe regroupait l'activité nécessaire au fonctionnement de cette page. L'objectif était de séparer l'interface du code et d'éviter ainsi que tout se retrouve sur une même page.
Le ViewState permettait de maintenir l'état de la page entre deux requêtes, mais entraînait souvent le transfert de volumineux blocs de données entre le client et le serveur. Ce ViewState prenait la forme d'un bloc de code chiffré inséré au début du code HTML de ce type de page Web.
Lorsque ces blocs étaient mal utilisés, ils pouvaient atteindre des centaines de Ko et agacer les internautes en ralentissant le chargement de la page. Ce n'était malheureusement pas le seul problème :
Le cycle de vie de la page était excessivement complexe et générait des erreurs de ViewState s'il n'était pas géré correctement.
La nature même des contrôles serveur faisait qu'il était difficile de modifier le code HTML qu'ils contenaient. Pour ne rien arranger, le code HTML et CSS de Microsoft ne respectait pas les standards du Web.
Même si la stratégie du code-behind donnait l'impression de séparer l'interface du code, cette séparation restait partielle, car il fallait toujours mêler code de présentation et logique métier.
Enfin, les formulaires Web sont arrivés avant la montée en puissance des tests automatiques. Par conséquent, il est presque impossible d'automatiser le test des formulaires Web.
Après avoir adopté l'architecture MVC, Microsoft a créé ASP.NET MVC. L'architecture MVC était utilisée depuis des années pour le développement d'applications logicielles, mais jusque-là, seul Ruby on Rails implémentait cette architecture pour le développement Web.
L'arrivée d'ASP.NET MVC a résolu une bonne partie des problèmes des formulaires Web en offrant les avantages suivants :
Enfin, une véritable séparation du code basée sur le principe de responsabilité unique. Nous étudierons ce principe plus en détail dans les chapitres suivants. Il s'agit sans doute du plus grand atout de l'architecture MVC, car il rend votre code propre, bien organisé, modulaire, facile à lire et à maintenir.
Contrôles HTML et CSS : fini les contrôles serveur. Vous pouvez désormais utiliser HTML et CSS en toute liberté.
Test unitaire : il est devenu plus simple de créer des tests unitaires pour vérifier votre code, car le ViewState et les autres objets de requête/réponse ne bloquent plus leur conception.
Meilleure optimisation pour les moteurs de recherche : les URL des formulaires Web portaient l'extension .aspx, tandis que les URL MVC n'ont aucune extension. On peut le voir par exemple avec l'URL http://localhost/Client/Liste. L'utilisation d'URL personnalisées permet que les moteurs de recherche reconnaissent plus facilement votre application.
Absence de ViewState : l'absence de ViewState accélère grandement l'affichage des pages et donc les performances de l'application.
Comme mentionné dans le premier point ci-dessus, la séparation des responsabilités constitue le principal atout de l'architecture MVC. Le diagramme ci-dessous montre comment le modèle, la vue et le contrôleur interagissent :
Que contient le modèle (M) ?
Pour faire simple, le modèle est un conteneur qui transfère les informations entre la vue et le contrôleur. Il ne dépend ni de l'un ni de l'autre et peut donc être testé de manière indépendante.
Le modèle ne doit pas contenir de logique métier, mais uniquement gérer les règles de validation et de mise en forme de ses propriétés publiques.
Voici un exemple de modèle en C# :
namespace ExempleMVC.Models
{
public class ModeleVueEtudiant
{
public int IdEtudiant { get; set; }
public string NomEtudiant { get; set; }
public int Age { get; set; }
}
}Qu'en est-il de la vue (V) ?
La vue correspond à ce que voit le visiteur, autrement dit à l'interface utilisateur. Elle affiche le modèle qui lui a été transmis. Le visiteur peut alors modifier le modèle comme dans un formulaire et le renvoyer au contrôleur.
ASP.NET MVC utilise un moteur de vue nommé Razor qui vous permet de mêler balises HTML et code serveur. Razor remplace les symboles <% %> des formulaires Web par le caractère @. Ces pages sont enregistrées avec l'extension .cshtml en C# et .vbhtml en Visual Basic.
Voici l'exemple d'une page de vue nommée Index.cshtml :
@model List<ModeleVueEtudiant>
<h2>Index</h2>
<p>
@Html.ActionLink("Nouveau", "Creer")
</p>
<table class="table">
<tr>
<th>
@Html.DisplayName("Nom")
</th>
<th>
@Html.DisplayName("Age")
</th>
<th>
</th>
</tr>
@foreach (var element in Model) {
<tr>
<td>
@Html.DisplayFor(m => element.NomEtudiant)
</td>
<td>
@Html.DisplayFor(m => element.Age)
</td>
<td>
@Html.ActionLink("Modifier", "Modifier", new { id=element.IdEtudiant }) | @Html.ActionLink("Détails", "Details", new { id=element.IdEtudiant }) | @Html.ActionLink("Supprimer", "Supprimer", new { id = element.IdEtudiant })
</td>
</tr>
}
</table>L'image ci-dessous montre comment la vue apparaît pour le visiteur :
Que contient le contrôleur (C) ?
C'est dans le contrôleur que tout se passe. Il gère la requête d'URL entrante à l'aide des méthodes action pour créer le modèle, récupérer les données, renseigner le modèle et le transmettre à la vue.
Dans ASP.NET MVC, chaque nom de classe du contrôleur doit se terminer par le mot "Controller" et hériter de la classeController . Par exemple, le contrôleur de la page de gestion des étudiants doit s'appeler EtudiantController.
Par ailleurs, si vous renvoyez simplement View(modele), le nom de la page .cshtml doit correspondre exactement à celui de la méthode utilisée. Dans notre exemple, Index doit renvoyer vers la page Index.cshtml.
Voici un exemple de contrôleur en C# :
using Microsoft.AspNetCore.Mvc;
using MVCExample.Models;
namespace ExempleMVC.Controllers
{
public class EtudiantController : Controller
{
// Récupération de la liste des étudiants
public IActionResult Index()
{
//renseigne un modèle avec la liste de tous les étudiants provenant d'une classe Service
List<ModeleVueEtudiant> modele = Service.RecupererEleves();
//renvoie le modèle avec la vue
return View(modele);
}
}
}
En résumé
L’architecture MVC permet de mieux séparer le code.
Le modèle correspond aux données échangées entre le contrôleur et la vue.
La vue est la page qui s'affiche sur le navigateur de l'utilisateur.
Le contrôleur gère la requête permettant de récupérer les données et de renseigner le modèle.
Avant de passer à la suite, répondez à un petit quiz pour confirmer que l'architecture MVC n'a plus de secret pour vous.
Dans la partie suivante, nous allons nous pencher plus en détail sur les principes de conception SOLID et les appliquer un par un.
