Ce week-end, j'ai finalement commencé à m'intéresser à la toute dernière mouture d'ASP.NET (oui, je sais, il était temps). Vous connaissiez peut-être le projet comme étant ASP.NET vNext, ou ASP.NET 5, mais sachez que le nouveau nom est tombé, et que le nouveau mot tendance pour 2016 (du moins dans le monde .NET) sera Core. ASP.NET MVC Core 1.0, ASP.NET Core 1.0 et .NET Core 1.0, ça en fait des Core. Mais voilà, ce mot fait une grande différence, car il met en évidence que ces produits n'ont de commun avec leur ancêtre que leur nom, ou presque. Et c'est une chance. Laissez-moi vous mettre en contexte.

Doublé par la droite il y a environ 10 ans par Ruby On Rails, puis par la gauche par le désormais célèbre Node.js, il fallait que Microsoft réagisse. Comparé à RoR, ASP.NET n'était pas assez web-friendly (rappelons-nous WebForms) et comparé à Node.js, ils étaient des dizaines de fois trop lents. Il fallait faire quelque chose, mais enseveli sous une décennie et demi de vieux code, l'équipe était au bout de ses ressources pour améliorer leur produit. Oui, ils avaient livrés MVC, mais ils avaient encore une forte dépendance au monolithique System.Web.dll. Il ne restait plus qu'une solution: Une réécriture complète. Je dois vous avouer dès maintenant que je suis agréablement surpris de la direction que l'équipe ASP.NET a prise. Dès le départ, ils se sont entendu que ce produit devait être multi-plateforme (officiellement, Windows, Linux et Mac) et devait transcender les simples limites d'une librairie. ASP.NET vNext devait forcer une réécriture complète du framework .NET et de ses outils (Visual Studio, le compilateur Roslyn, le gestionnaire de paquets NuGet). Vous comprendrez que ce n'est pas un petit update de sécurité et que vos applications précédentes ne seront probablement pas compatibles avec cette nouvelle version sans effort comme c'était le cas par le passé.

.NET sous Linux

Comme je l'ai mentionné plus haut, Microsoft supportera désormais officiellement son framework .NET sous Linux, sous Mac et sous Windows, et c'est une agréable surprise. On savait depuis le début que .NET avait le potentiel d'être autant multi-plateforme que Java, mais que Microsoft n'était pas intéressé à s'aventurer dans ce portage (c'est plutôt Mono qui s'en est chargé). Cependant, comme MS n'a pas l'intention immédiate de porter toutes les parties de son framework (WinForms, WebForms, WPF, WCF, WF), .NET se déclinera maintenant en deux saveurs: la classique et la Core.

.NET 2015
Un schéma des deux "saveurs" du nouveau .NET.

Les deux frameworks contiennent un ensemble de classes et d'outils communs que l'on appelle la Base Class Library (ou BCL), en plus de partager le nouveau JIT et le nouveau compilateur Roslyn. Cependant, leur fonctionnement interne diffère grandement. La saveur Core est complètement Open Source, tient à l'intérieur d'un croquette (paquet NuGet) de quelques Mo et permet d'être exécutée simultanément à une autre version de .NET (que ce soit classique ou Core). Avez-vous déjà eu à choisir une ancienne version du framework .NET par contrainte de ne pas briser une autre application qui serait hébergée sur le même serveur? Maintenant, il suffira d'avoir l'outil de base nommé dnvm pour installer n'importe qu'elle version du framework et le charger dans le contexte d'une console. Cela est possible car .NET Core s'affranchit du GAC et des dépendances systèmes. Maintenant, tout se trouvera dans le dossier bin et sera résolu (idéalement) par croquette. D'ailleurs, .NET Core s'installe directement dans le dossier utilisateur, ne demandant aucune autorisation Administrateur. Et cerise sur le gâteau, ASP.NET Core a même été pensé et créé afin de pouvoir s'exécuter facilement sur chacune de ces saveurs selon votre goût et vos préférences.

Middlewares et IIS en instance de divorce

Avec les anciennes versions d'ASP.NET, nous n'avions pas vraiment le choix: il fallait héberger sous IIS, merci à notre ami System.Web.dll. Bien que IIS soit un bon produit, le couplage était tel que IIS savait comment interagir de manière intime avec les applications ASP.NET. Les modules HTTP étaient un bon exemple de ce couplage fort. Avec la nouvelle version d'ASP.NET, ce couplage n'existe plus. On peut donc tirer avantage des modèles plus modernes avec un proxy inversé, comme sur Node.js avec nginx.

À la place du pipeline d'éxecution d'ASP.NET, la nouvelle version Core fait maintenant usage de middlewares grandement inspirés de Node.js et d'Express. Les middlewares sont des morceaux de code qui enrobent l'exécution d'une requête. L'ordre dans lesquels ils sont déclarés impacte grandement la réponse, car un middleware pourra affecter une requête en effectuant des actions soit à l'entrée d'une requête, soit à la sortie d'une réponse. Les actions qui peuvent être effectués sont variés, car un middleware peut à la fois augmenter une requête (par exemple en effectuant l'identification de l'utilisateur), générer une réponse (en ce faisant, tous les autres middlewares déclarés après ne seront pas exécutés), augmenter une réponse et plus encore! Regardez ce schéma, cela devrait vous aider à comprendre.

Fonctionnement des middlewares
Les middlewares augmentent une requête (sécurité, identification, logging) ou la complètent.


En bref, terminé le pipeline d’événements difficile à suivre. Vous êtes maintenant en charge de construire votre propre pipeline comme bon il vous semblera. Cela peut sembler anodin, mais cette responsabilité vient avec une grande récompense: Vous décidez maintenant de ce qui s'exécute, et cela signifie que vous ne paierez que pour ce que vous utilisez en terme de performance. Vous n'avez pas besoin d'authentification car vous faites un site public? Ne prenez pas ce module. Vous n'avez pas besoin de CORS? N'en payez pas le prix! Le résultat de tout ça est une meilleure sécurité (qui n'a jamais oublié de retirer les pages d'erreurs d'ASP.NET en production) et une performance à laquelle on ne s'attendait plus des applications ASP.NET. Et ne pensez pas que la performance n'est qu'une conséquence de l'approche. Non, car l'équipe d'ASP.NET y met beaucoup d'amour, et cela paraît avec le nouveau serveur Kestrel.

Une tonne d'autres améliorations

Il reste une tonne d'autres améliorations à couvrir. Je ne vais que les lister: Injection des dépendances, nouveau systèmes de configuration, framework cloud-ready, unification de MVC et de WebAPI, et j'en passe. Dans un prochain article, j'aimerais couvrir un peu plus en détail de fonctionnement de certaines fonctionnalités, dont MVC Core, les middlewares (avec des exemples de code) et le nouveau NuGet pour ne nommer que ceux-là.

Est-ce que cette nouvelle mouture aura le pouvoir de renverser la vapeur et rendre à ASP.NET sa superbe et lui garantir une popularité dans le monde Open Source? C'est à voir.

Quelques ressources