Les nouveaux mécanismes d’ASP.NET Core

Introduction

La nouvelle version d’ASP.NET Core intègre plusieurs nouveaux mécanismes qui permettent aux développeurs de mieux gérer certains aspects de leurs projets. Dans les versions précédentes, lorsque le projet nécessitait l’exposition d’API au travers de l’application web, la brique Web API proposait ses propres API et classes afin d’exposer des services vers l’extérieur. Par exemple, il existait une classe de base ApiController pour les API et une classe Controller pour les pages de l’application, alors que le fonctionnement d’un contrôleur est toujours le même : récupérer la requête HTTP, traiter les données et renvoyer une réponse.

Il en est de même pour l’accès aux données qui était souvent fastidieux. Le code métier était pollué de plusieurs blocs using afin de s’assurer que la connexion à la base de données était bien fermée. Cela est sans conteste une bonne pratique que de fermer la connexion au plus tôt, mais la lisibilité du code subissait les conséquences. ASP.NET Core intègre un nouveau système de dépendances permettant de mieux gérer ce genre de cas, et d’augmenter la maintenabilité du code métier.

Ce chapitre va traiter de quelques nouveautés extrêmement...

L’injection de dépendances

L’injection de dépendances d’ASP.NET Core est un ensemble de services et de mécanismes préintégrés au framework afin d’injecter des services dans toute l’application. Dans les versions précédentes, le développeur avait besoin d’un framework externe alors que maintenant ce n’est plus nécessaire.

Le principe de l’injection de dépendances est une technique consistant à coupler faiblement les objets et les classes de services entre elles et leurs dépendances. Au lieu d’instancier directement les services dans les méthodes par l’intermédiaire des constructeurs ou des using, la classe va déclarer quelles sont les dépendances dont elle a besoin pour fonctionner. La plupart du temps, la classe va déclarer ses dépendances dans son constructeur : ce procédé est appelé constructor injection, et permet de respecter les bonnes pratiques intitulées Explicit Dependencies Principle. Le but étant que la classe expose de manière explicite ses dépendances dans le constructeur.

Cependant, il est important de concevoir sa classe en gardant le principe de DI (Dependency Injection) en tête et de garder ses services faiblement couplés avec ses dépendances. Une autre bonne pratique intitulée Dependency Inversion Principle énonce une phrase qui résume très bien la philosophie de DI :

"High level modules should not depend on low level modules; both should depend on abstractions."

Cette phrase est très révélatrice de la méthode à adopter lorsqu’on fait de l’injection de services dans les classes : il faut injecter une abstraction de cette classe, et non la classe elle-même. En C#, cela reviendrait à déclarer une interface comme étant une dépendance de la classe. Ce principe de déporter les dépendances dans des interfaces et de fournir des implémentations concrètes est également un exemple du pattern Strategy Design.

Lorsqu’un système est conçu pour utiliser l’injection de dépendances, il a besoin d’un conteneur de dépendances pour répertorier tous les services qui sont potentiellement...

Les middlewares

Les middlewares sont un nouveau concept introduit avec ASP.NET Core faisant partie de la spécification Open Web Interface for .NET (OWIN). Le but d’OWIN est de découpler le serveur et l’application tout en conservant un standard ouvert et afin de stimuler l’écosystème open source .NET Web. Voici les termes importants définis par OWIN :

Les middlewares sont donc des composants (de manière concrète ce sont des classes C#) qui seront chaînés et qui vont intervenir chacun leur tour sur la requête HTTP. Chaque middleware va ainsi décider s’il laisse passer ou non la requête au middleware suivant en fonction de l’action qu’il vient d’effectuer sur la requête. Un délégué de requête est utilisé pour construire le pipeline de la requête. C’est à chaque middleware de passer la main au suivant via ce délégué de requête, ou bien de court-circuiter le chaînage en fonction du besoin.

La configuration des middlewares s’effectue dans la méthode Configure de la classe Startup en utilisant les méthodes d’extensions Run, Map et Use.

Schéma de l’enchaînement des middlewares

L’intérêt du court-circuitage de la requête par les middlewares est d’éviter des traitements inutiles. En effet, si l’utilisateur veut accéder à une page qui demande une authentification, et si le middleware détecte que cet utilisateur...

Les Web API

Le protocole HTTP ne permet pas seulement de renvoyer des pages HTML avec du CSS et du JavaScript, il permet également de construire des API qui exposent des services et des données. Le but de ces API est de rendre accessibles certaines données de votre site, mais aussi que quelqu’un de l’extérieur puisse interagir avec ce site, en insérant par exemple des enregistrements ou en récupérant une liste d’informations. La chose importante à retenir est que ces API permettent d’intégrer des points d’entrée supplémentaires pour le système. 

ASP.NET Core a simplifié l’utilisation des API en unifiant le framework. Aujourd’hui, un site web développé avec ASP.NET Core va permettre de renvoyer du HTML et des API tout en conservant le même code de base, et également le même pipeline HTTP.

Schéma de l’unification du framework

De manière concrète, les API sont simplement représentées par des contrôleurs MVC qui possèdent une route bien distincte des autres routes classiques. Cependant, il est nécessaire de bien réfléchir à l’organisation de ces contrôleurs, car leur utilisation n’est pas la même. Un contrôleur Web Pages va répondre suivant un protocole bien précis, qui est /controller/action, ce sont donc les actions qui dictent quelle vue sera renvoyée.

Pour les contrôleurs API, ces derniers vont répondre selon la méthode HTTP utilisée, c’est-à-dire GET, POST, PUT ou DELETE. Par exemple, la réponse de l’API /api/product ne sera pas la même si la méthode est GET ou PUT. Il est donc important de concevoir les API autour des méthodes HTTP plutôt qu’autour des actions qu’elles exposent. Évidemment, il est toujours possible d’exposer des routes particulières pour des API en fonction des besoins. Pour rappel, les méthodes importantes sont :

Les API minimales

Au sein d’une industrie qui évolue rapidement, les pratiques d’architecture et de développement voient émerger de nouveaux concepts. L’un de ces concepts est le microservice, c’est-à-dire le développement d’une application minimaliste, ciblée sur un domaine métier particulier, possédant sa propre base de données et n’exposant que les API nécessaires à la gestion de ce domaine.

Afin de répondre à la demande grandissante de ce type de développement, les équipes de Microsoft ont introduit la possibilité de créer des applications web ASP.NET Core en incluant le minimum de code nécessaire pour créer des API.

Le code ci-dessous est suffisant pour faire fonctionner l’application et expose une API qui retourne une chaîne de caractères. Dans ce cas précis, le développeur n’a pas besoin de passer par tous les dossiers et fichiers composant traditionnellement une application Web API (omme les dossiers Controllers et Areas par exemple).

var app = WebApplication.Create(args);  
app.MapGet("/", () => "Hello World!");  
app.Run(); 

La ligne WebApplication.Create va s’occuper de rajouter dans l’application toutes les couches nécessaires au bon fonctionnement de l’application : routing, injection de service, gestion des contrôleurs, gestion des configurations, et ainsi de suite. Le développeur n’a plus qu’à définir ses routes via la méthode MapGet, puis de lancer l’application avec la méthode Run. Afin de créer les API, il existe plusieurs méthodes...