Qu’est-ce que ASP.NET ?

ASP.NET est un framework de dé­ve­lop­pe­ment so­phis­ti­qué de Microsoft côté serveur. Les dé­ve­lop­peurs utilisent ASP.NET pour mettre en œuvre des sites Web dy­na­miques, des ap­pli­ca­tions Web et des services basés sur le Web. Après des décennies de dé­ve­lop­pe­ment, le framework se poursuit aujourd’hui sous le nom d’ASP.NET Core.

Développé à l’origine par Microsoft, ASP.NET fait désormais partie de la .NET Foun­da­tion. Alors que les premières versions étaient encore publiées en tant que logiciel pro­prié­taire, l’ASP.NET moderne est un projet open source.

L’ASP.NET utilisé aujourd’hui est le résultat d’un processus de dé­ve­lop­pe­ment qui s’est étendu sur plusieurs décennies. ASP est devenu ASP.NET, puis ASP.NET Core. Dans le cadre des progrès réalisés par la tech­no­lo­gie Web, le framework a ra­di­ca­le­ment changé au fil des ans. In­té­res­sons-nous tout d’abord à l’his­to­rique du dé­ve­lop­pe­ment d’ASP.NET :

L’« Active Server Pages » (ASP) original fut le premier langage de script côté serveur publié par Microsoft. Active Server Pages a permis la création dynamique de pages Web sur le serveur à partir de 1996. Alors que d’autres langages de script s’appuient sur Linux comme système d’ex­ploi­ta­tion et sur un serveur Web open source tel qu’Apache, Microsoft a intégré les Active Server Pages au « Internet In­for­ma­tion Server » (IIS) fonc­tion­nant sous Windows.

La fonc­tion­na­lité de base d’ASP est à peu près com­pa­rable à celle de PHP ou des « Java Server Pages » (JSP). Des fichiers modèles sont utilisés dans les trois tech­no­lo­gies. Les fichiers modèles con­tien­nent des extraits de code exé­cu­tables qui sont intégrés au contenu HTML statique. Le code est écrit entre des balises spéciales pour le séparer du code HTML en­vi­ron­nant. Les langages VBScript, JScript et PerlS­cript, dis­po­nibles à l’époque et spé­ci­fiques à Microsoft, étaient utilisés comme langages de pro­gram­ma­tion.

Lorsqu’un na­vi­ga­teur accède à une URL (« Request »), le code est exécuté sur le serveur. L’exécution génère du contenu HTML qui est inséré dans les struc­tures HTML pré­dé­fi­nies. Le résultat global est un document composé de contenu HTML statique et dynamique ; celui-ci est transmis au na­vi­ga­teur en tant que réponse (« Response ») et affiché à l’uti­li­sa­teur. Toute mo­di­fi­ca­tion du contenu de la page, par exemple par une entrée de l’uti­li­sa­teur, né­ces­si­tait un cycle complet de requête-réponse et donc un re­char­ge­ment de la page. Voici un exemple de code ASP :

ASP n’était pas encore un framework. Il s’agissait bien plus d’une col­lec­tion dissociée de plusieurs objets per­met­tant, une fois associés, de cons­ti­tuer un site Web dynamique :

• Ap­pli­ca­tion
• Request
• Response
• Server
• Session
• ASPError

ASP.NET, le suc­ces­seur de l’ASP classique, a été introduit vers 2003. La col­lec­tion dissociée d’objets a été remplacée par le framework .NET utilisé comme sous-structure. Cela a permis d’abstraire des processus fré­quem­ment requis, tels que l’au­then­ti­fi­ca­tion et l’au­to­ri­sa­tion des uti­li­sa­teurs ou encore l’accès aux bases de données. De manière générale, ASP.NET est à peu près com­pa­rable aux fra­me­works Java tels que « Struts » ou « Spring ».

ASP.NET a inclus les « Web Forms » comme ca­rac­té­ris­tique es­sen­tielle. L’approche des Web Forms a permis aux dé­ve­lop­peurs Windows ex­pé­ri­men­tés de pro­gram­mer des sites Web dy­na­miques. Les mé­ca­nismes sous-jacents du Web étaient cachés aux dé­ve­lop­peurs et ces derniers pouvaient continuer à utiliser les flux de travail et les en­vi­ron­ne­ments de dé­ve­lop­pe­ment qui leur étaient familiers. Des outils visuels de dé­ve­lop­pe­ment rapide d’ap­pli­ca­tions (RAD) spé­ci­fiques à Microsoft ont en par­ti­cu­lier été utilisés.

Les Web Forms ont permis aux dé­ve­lop­peurs Windows de se lancer ra­pi­de­ment dans la pro­gram­ma­tion Web. Dans le même temps, cette approche limitait cependant le degré de contrôle sur les pages HTML livrées.ASP.NET Un modèle de dé­ve­lop­pe­ment al­ter­na­tif a ra­pi­de­ment été ajouté avec ASP.NET MVC. Ce modèle suit le modèle établi de « Model View Con­trol­ler » (MVC) et permet une sé­pa­ra­tion plus nette des préoc­cu­pa­tions. Basé sur le framework pionnier « Ruby on Rails », ASP.NET MVC offrait une fonc­tion­na­lité per­met­tant d’« écha­fau­der » un projet.

Aujourd’hui, ASP.NET a été remplacé par son évolution « ASP.NET Core ». Dans le langage courant, les deux noms sont cependant souvent utilisés comme synonymes.

Avec la sortie d’ASP.NET Core, l’or­ga­ni­sa­tion du framework a changé. Dans le cadre de l’ouverture pro­gres­sive de Microsoft, le dé­ve­lop­pe­ment d’ASP.NET Core a été placé sous l’égide de la .NET Foun­da­tion. Le code source du projet est dis­po­nible sous une licence open source.

Sur le plan technique, ASP.NET Core est une refonte d’ASP.NET 4.0. Les com­po­sants d’ASP.NET qui ont été dé­ve­lop­pés de manière organique ont été fusionnés. Le dé­ve­lop­pe­ment de projets ASP.NET Core et l’hé­ber­ge­ment en dehors de l’éco­sys­tème Windows ont été rendus possibles. Sous Windows, ASP.NET Core est basé sur le framework .NET ; les autres systèmes d’ex­ploi­ta­tion ont, quant à eux, recours au framework .NET Core.

Dans le droit fil du dé­ve­lop­pe­ment continu de la tech­no­lo­gie Web, ASP.NET Core est paré pour le Cloud. En plus du serveur Internet In­for­ma­tion Server (IIS) tra­di­tion­nel­le­ment utilisé par Microsoft, des en­vi­ron­ne­ments de serveurs ouverts et des con­te­neurs sont utilisés comme en­vi­ron­ne­ment d’hé­ber­ge­ment ASP.NET. Le framework prend en charge le code côté client et les approches modernes de la pro­gram­ma­tion réactive. ASP.NET Core se place ainsi au même niveau que les fra­me­works basés sur Ja­vaS­cript tels que React.

Des projets Web de toutes sortes peuvent être mis en œuvre avec ASP.NET Framework, tels que des sites Web dy­na­miques et des ap­pli­ca­tions Web, y compris les « Single Page Apps » (SPA). Des services Web tels que des API et des systèmes de com­mu­ni­ca­tion en temps réel peuvent également être im­plé­men­tés. Au fil des ans, dif­fé­rentes approches ont été utilisées à des fins diverses. Nous les abor­de­rons ci-dessous et nous vous donnerons un aperçu de l’évolution his­to­rique.

Avec l’avancée des tech­no­lo­gies Web depuis les années 2000, de nouvelles approches du dé­ve­lop­pe­ment Web ont été intégrées à ASP.NET. Vous pouvez les con­si­dé­rer comme une boîte à outils bien organisée : dif­fé­rents outils sont dis­po­nibles pour dif­fé­rents types de projets. En fonction des besoins, plusieurs approches peuvent être combinées dans un même projet. Avec l’ap­pa­ri­tion d’ASP.NET Core, les nombreux modèles de pro­gram­ma­tion dé­ve­lop­pés de manière organique ont été fusionnés per­met­tant ainsi une sim­pli­fi­ca­tion dans le choix des approches ap­pro­priées.

Les Web Forms clas­siques per­met­tent d’assembler des pages à partir de com­po­sants pré­dé­fi­nis. Pour ce faire, un kit de cons­truc­tion de for­mu­laire visuel est utilisé ; les dif­fé­rents com­po­sants sont po­si­tion­nés par glisser-déposer. Cette pos­si­bi­lité était par­ti­cu­liè­re­ment in­té­res­sante pour les dé­ve­lop­peurs ayant une ex­pé­rience de la pro­gram­ma­tion Windows. Ils ont pu utiliser les outils qui leur étaient familiers pour le « Rapid Ap­pli­ca­tion De­ve­lop­ment » (RAD), à ceci près que le produit final n’était pas une ap­pli­ca­tion Windows, mais un site Web dynamique.

L’approche Web Forms est basée sur le modèle code-behind de Microsoft qui renforce la sé­pa­ra­tion des préoc­cu­pa­tions :

• Les fichiers modèles avec l’extension .aspx dé­fi­nis­sent la structure HTML d’une page et con­tien­nent des espaces réservés pour le contenu généré dy­na­mi­que­ment
• La logique d’ap­pli­ca­tion pro­pre­ment dite est stockée dans un fichier distinct avec l’extension .aspx.cs ou .aspx.vb. C’est le fichier code-behind qui lui donne son nom.
• Le client récupère le fichier .aspx dis­po­nible sous une URL. Les com­po­sants statiques et dy­na­miques sont combinés sur le serveur et le document HTML résultant est livré au client.
• Lorsque l’uti­li­sa­teur saisit des données sur la page, celles-ci sont trans­fé­rées vers la même URL via une requête GET ou POST et sont traitées par le fichier code-behind.

Pour la mise en œuvre de la logique de l’ap­pli­ca­tion, une approche orientée objet est utilisée : le fichier code-behind définit une classe dérivée. Le langage de pro­gram­ma­tion utilisé est gé­né­ra­le­ment C# ou Visual Basic. Il est in­té­res­sant de noter que le fichier code-behind est pré­com­pilé une fois. Cela permet une exécution plus rapide et une plus grande ré­sis­tance aux erreurs lors de l’appel de la page.

Con­trai­re­ment à l’ASP d’origine, les Web Forms ont constitué un pas en avant vers la sé­pa­ra­tion des préoc­cu­pa­tions. Avec ASP, le HTML statique et les com­po­sants de code étaient mélangés dans un seul et même fichier. Les Web Forms ont permis la sé­pa­ra­tion entre le modèle et le fichier code-behind. Avec ASP.NET MVC, ASP.NET s’est vu doter d’un autre modèle de pro­gram­ma­tion qui permet un dé­ve­lop­pe­ment Web basé sur le modèle Model View Con­trol­ler (MVC).

Le modèle MVC sépare la logique de l’ap­pli­ca­tion (« Model »), le modèle de pré­sen­ta­tion (« View » et l’in­te­rac­tion avec l’uti­li­sa­teur (« Con­trol­ler »). L’un des avantages de l’approche MVC est que les préoc­cu­pa­tions in­di­vi­duelles peuvent être testées plus fa­ci­le­ment. De plus, la sé­pa­ra­tion des préoc­cu­pa­tions permet d’utiliser dif­fé­rents con­trô­leurs. Par exemple, au lieu d’envoyer toutes les entrées de l’uti­li­sa­teur vers une seule URL et de recharger la page, on utilise AJAX via jQuery ce qui permet de recharger certaines parties de la page. Avec ASP.NET Core MVC, la tradition d’ASP.NET MVC se poursuit dans la version actuelle du framework.

Les Web Forms ASP.NET et ASP.NET MVC con­vien­nent par­fai­te­ment à la réa­li­sa­tion de sites Web complexes. Si vous avez besoin de plusieurs pages avec des com­po­sants réu­ti­li­sables, les deux modèles de pro­gram­ma­tion peuvent s’y prêter. Mais que faire si cela est superflu ? Supposons que vous vouliez créer un site Web simple, composé d’une seule ou de quelques pages. Vous disposez de quelques com­po­sants dy­na­miques, mais l’accent est davantage mis sur une mise en page so­phis­ti­quée que sur une logique d’ap­pli­ca­tion complexe et le trai­te­ment des entrées de l’uti­li­sa­teur. Dans ce cas, il serait exagéré de définir vos propres classes ou de viser une ré­par­ti­tion selon le modèle MVC.

Les pages Web ASP.NET cons­ti­tuent un bon choix dans les cas où la logique de l’ap­pli­ca­tion est moins im­por­tante que la mise en page et la con­cep­tion so­phis­ti­quéeASP.NET. Comme pour l’ASP ou le PHP classique, une com­bi­nai­son de struc­tures HTML statiques et de com­po­sants de code dy­na­miques a lieu dans un fichier. Pour cela, une syntaxe spéciale est utilisée. Les pages Web ASP.NET sont par­ti­cu­liè­re­ment adaptées à la création de pages de renvoi.

Les modèles de pro­gram­ma­tion présentés jusqu’à présent visent tous à générer du contenu HTML destiné à des uti­li­sa­teurs humains. En outre, ASP.NET Framework contient également des modèles qui servent à fournir une in­fras­truc­ture pour les projets Web. L’API Web ASP.NET est un modèle de pro­gram­ma­tion per­met­tant de créer des API REST. L’accès aux points de ter­mi­nai­son de l’API se fait via AJAX. Pour la trans­mis­sion des données, on utilise le format JSON ou XML.

ASP.NET WebHooks est une im­plé­men­ta­tion du modèle WebHooks. Les WebHooks vous per­met­tent de publier et de vous abonner à des évé­ne­ments qui ont lieu dans un système. Il peut s’agir, par exemple, de l’ajout d’un fichier ou de la réception d’un paiement. Un abonné en­re­gistre le chan­ge­ment à suivre auprès du système de pu­bli­ca­tion. Pour ce faire, il transmet une URL, le WebHook à qui il doit son nom. Lorsque l’événement en­re­gis­tré se produit, le système de pu­bli­ca­tion appelle le WebHook ; l’abonné est informé de l’événement.

SignalR est un framework pour la com­mu­ni­ca­tion en temps réel entre le client et le serveur. Le framework est basé sur la norme Web­So­ckets et permet le transfert bi­di­rec­tion­nel de données. Les na­vi­ga­teurs qui ne prennent pas en charge les Web­So­ckets sont pris en charge par des mé­ca­nismes de secours. SignalR est souvent utilisé pour mettre en œuvre des services de chat basés sur un na­vi­ga­teur et des logiciels de vi­déo­con­fé­rence.

ASP.NET Core est le suc­ces­seur d’ASP.NET. Le framework ASP.NET Core a été réécrit, mais est hautement com­pa­tible avec son pré­dé­ces­seur. Dans la version Core, les com­po­sants d’ASP.NET qui étaient séparés ont été fusionnés. De plus, certains com­po­sants ont été nou­vel­le­ment dé­ve­lop­pés et ont conservé leurs noms existants. Par exemple, le framework SignalR existe à la fois en version ASP.NET et ASP.NET Core. Jetons un œil aux nouveaux dé­ve­lop­pe­ments majeurs d’ASP.NET Core.

ASP.NET Core MVC combine les fonc­tion­na­li­tés d’ASP.NET MVC et de l’API Web ASP.NET. Cela permet de dé­ve­lop­per des ap­pli­ca­tions Web hautement dy­na­miques avec une interface uti­li­sa­teur et une API sous-jacente mo­du­laires. Le framework .NET Core est utilisé comme base commune. Les approches fa­mi­lières du dé­ve­lop­pe­ment API de .NET peuvent être trans­fé­rées au dé­ve­lop­pe­ment MVC et vice versa.

Les pages Razor occupent un créneau similaire à celui des anciennes pages Web ASP.NET. Elles peuvent être utilisées dans les cas où le modèle Model-View-Con­trol­ler re­pré­sen­te­rait une surcharge inutile. Si vous souhaitez par exemple créer une page de renvoi, vous pouvez la mettre en œuvre comme une page Razor sans trop d’efforts. La syntaxe Razor est utilisée pour créer le modèle de page. Comme d’habitude dans l’univers .NET, C# et Visual Basic peuvent être utilisés comme langages de pro­gram­ma­tion.

Jetons un œil à un exemple de page Razor. Il est à noter qu’un signe @ initial est utilisé à la place des balises de code d’ouverture et de fermeture ha­bi­tuelles des langages de modèle :

Le framework Blazor repose sur la syntaxe Razor sus­men­tion­née ; en fait, Blazor est l’acronyme de « Browser + Razor ». Comme son nom l’indique, Blazor se concentre sur le na­vi­ga­teur en tant qu’en­vi­ron­ne­ment d’exécution. Avec Razor Pages, le trai­te­ment de l’in­te­rac­tion de l’uti­li­sa­teur a lieu sur le serveur. Blazor permet une pro­gram­ma­tion réactive, dans laquelle les com­po­sants in­di­vi­duels de la page dans le na­vi­ga­teur réa­gis­sent dy­na­mi­que­ment aux chan­ge­ments. De ce point de vue, Blazor est à peu près com­pa­rable aux tech­no­lo­gies React, Angular et Vue.

Voici un exemple simple de pro­gram­ma­tion réactive avec Blazor. Nous lions la valeur d’un champ de saisie à la variable Name. La syntaxe Razor est utilisée pour cela :

Outre la pro­gram­ma­tion réactive, une autre fonc­tion­na­lité de Blazor est très in­té­res­sante : les langages .NET peuvent être compilés via We­bAs­sem­bly pour une exécution dans le na­vi­ga­teur. C’est la raison pour laquelle on appelle parfois Blazor l’approche « .NET in the browser ». L’avantage est qu’il n’est pas né­ces­saire d’écrire du Ja­vaS­cript pour le code côté client. Au lieu de cela, le dé­ve­lop­pe­ment se fait en C# ou Visual Basic ; le code peut accéder aux com­po­sants familiers du framework .NET.

ASP.NET ou ASP.NET Core offre un en­vi­ron­ne­ment mature pour le dé­ve­lop­pe­ment d’une grande variété de projets Web. Le champ d’ap­pli­ca­tion comprend les langages de pro­gram­ma­tion, les éditeurs de code et les IDE ainsi que les outils de dé­ve­lop­pe­ment et un éco­sys­tème flo­ris­sant de packages dis­po­nibles gra­tui­te­ment. De nos jours, des méthodes modernes telles que la pro­gram­ma­tion réactive, Web­So­ckets et We­bAs­sem­bly sont utilisées. Le plus grand in­con­vé­nient à l’uti­li­sa­tion d’ASP.NET était tra­di­tion­nel­le­ment son étroite relation avec Microsoft et le Vendor Lock-in qui en découlait. Avec l’ouverture pro­gres­sive vers l’open source, cette question est désormais moins préoc­cu­pante.

Les dé­ve­lop­peurs fa­mi­lia­ri­sés avec la pro­gram­ma­tion dans l’éco­sys­tème Microsoft sont ceux qui gagnent le plus à utiliser ASP.NET. Ils peuvent fa­ci­le­ment accéder aux langages, outils et workflows qui leur sont familiers. Le framework mature .NET est utilisé comme base d’ASP.NET. Cela signifie que des com­po­sants adaptés sont dis­po­nibles pour une grande variété d’ap­pli­ca­tions. C’est un avantage con­si­dé­rable lorsqu’il s’agit de mettre en œuvre des ap­pli­ca­tions complexes ra­pi­de­ment et avec des résultats fiables.

Le framework .NET a une structure modulaire et contient le « Common Language Runtime » (CLR) en tant qu’en­vi­ron­ne­ment d’exécution. Cela permet l’uti­li­sa­tion de divers langages de pro­gram­ma­tion, pour autant qu’ils soient conformes à la norme « Common Language In­fras­truc­ture » (CLI). En plus des langages clas­siques orientés objet C# et Visual Basic, les langages CLI dé­ve­lop­pés par Microsoft com­pren­nent le nouveau langage fonc­tion­nel F#. Les langages CLI peuvent être exécutés en tant que code côté client dans le na­vi­ga­teur via Blazor et We­bAs­sem­bly.

À l’origine, ASP.NET était un logiciel pro­prié­taire sous le contrôle de Microsoft. Aujourd’hui, c'est un projet open source sous l’égide de la .NET Foun­da­tion. Au cours de cette ouverture, le ges­tion­naire de paquets NuGet et le dépôt public associé ont été mis en place. Com­pa­rable à NPM ou RubyGems, ASP.NET met ainsi à dis­po­si­tion des dé­ve­lop­peurs un éco­sys­tème de paquets librement uti­li­sables.

Le plus grand avantage d’ASP.NET, c’est-à-dire l’uti­li­sa­tion de l’éco­sys­tème propre à Microsoft, est également le plus grand in­con­vé­nient de cette tech­no­lo­gie. En effet, le dé­ve­lop­pe­ment Web repose en grande partie sur des plates-formes, des langages et des formats libres et ouverts. Les dé­ve­lop­peurs qui plongent pour la première fois dans l'univers .NET sont con­fron­tés à une variété dé­con­cer­tante de versions et de modèles de pro­gram­ma­tion.

Tra­di­tion­nel­le­ment, toute personne sou­hai­tant dé­ve­lop­per avec le framework ASP.NET ne pouvait le faire que sous Windows. Depuis des années, Microsoft fait un effort concerté pour s’ouvrir aux normes largement utilisées et à l’open source. Avec l’ap­pa­ri­tion d’ASP.NET Core, le dé­ve­lop­pe­ment fonc­tionne désormais également sur les trois grandes familles de systèmes d’ex­ploi­ta­tion Windows, macOS et Linux. En outre, il est désormais possible de conserver l’en­vi­ron­ne­ment de dé­ve­lop­pe­ment dans un conteneur Docker.

L’ASP.NET classique ne pouvait être hébergé que sur la tech­no­lo­gie de serveur de Microsoft, Internet In­for­ma­tion Server (IIS). C’est un in­con­vé­nient majeur par rapport aux autres fra­me­works Web, qui fonc­tion­nent tous également sous Linux. L’hé­ber­ge­ment ASP.NET a des exigences par­ti­cu­lières et n’est pas dis­po­nible auprès de tous les four­nis­seurs. Même s’il était possible d’utiliser d’autres serveurs Web avec « Mono » en tant qu’im­plé­men­ta­tion .NET gratuite, le véritable chan­ge­ment n’est intervenu qu’avec l’ap­pa­ri­tion de .NET Core et de l’« Open Web Interface for .NET » (OWIN). En effet, OWIN permet de découpler une ap­pli­ca­tion ASP.NET du serveur Web sous-jacent, levant ainsi l’un des prin­ci­paux obstacles à l’uti­li­sa­tion d’ASP.NET.

Le framework ASP.NET est spé­ci­fique à l’en­vi­ron­ne­ment d’hé­ber­ge­ment. Les autres fra­me­works Web basés sur les langages PHP, Java, Python ou Ja­vaS­cript fonc­tion­nent tous sur des serveurs Linux. Tra­di­tion­nel­le­ment, seul l’hé­ber­ge­ment d’ap­pli­ca­tions ASP.NET né­ces­si­tait Windows comme système d’ex­ploi­ta­tion du serveur. En outre, le serveur Web Internet In­for­ma­tion Services (IIS) de Microsoft était obli­ga­toire. Pour héberger une ap­pli­ca­tion ASP.NET sur des serveurs Windows, il convient de choisir l’hé­ber­ge­ment géré Windows. Avec ce modèle d’hé­ber­ge­ment, les serveurs sont cons­tam­ment en­tre­te­nus par le four­nis­seur et alimentés avec des mises à jour lo­gi­cielles.

L’hé­ber­ge­ment d’ap­pli­ca­tions ASP.NET Core est beaucoup plus simple. Outre IIS, elles peuvent être hébergées sur divers en­vi­ron­ne­ments de serveurs. On utilise le serveur Web intégré Kestrel, qui fonc­tionne sous Windows, Linux et macOS. Les serveurs Web po­pu­laires tels que Nginx et Apache peuvent être con­fi­gu­rés en tant que Reverse Proxy et utilisés avec Kestrel. L’al­ter­na­tive Kestrel HTTP.sys est également dis­po­nible sous Windows.