I. Les pages Web n'ont plus rien à envier aux interfaces client-serveur▲
On peut désormais concevoir la partie graphique d'une page Web comme on le fait pour l'interface graphique d'une application Visual Basic, Visual C++, Delphi ou, plus récemment, Windows Forms : en faisant glisser des contrôles graphiques depuis une barre d'outils.
Mais la comparaison ne s'arrête pas là. Oublier le mélange parfois indigeste de script serveur et de balises HTML : le contenu graphique et l'implémentation du code de la page sont désormais clairement séparés (soit dans deux sections au sein d'un même fichier, soit dans deux fichiers distincts - technique du code-behind). Ce nouveau modèle d'architecture rend les pages ASP.NET plus structurées, donc plus faciles à développer et maintenir.
Mais l'exemple le plus impressionnant du mimétisme entre pages Web et interfaces client-serveur est accompli grâce aux mécanismes de gestion événementielle et de conservation de l'état (ViewState), qui permettent d'ajouter de l'interactivité à des pages Web sans avoir recours explicitement à des scripts clients : une page ASP.NET peut détecter un événement côté client (par exemple, un changement de sélection dans une liste de catégories de produits) et provoquer l'appel d'un gestionnaire d'événement associé côté serveur (par exemple, l'affichage de la liste des produits correspondant à la catégorie nouvellement sélectionnée), le tout en donnant l'illusion qu'il s'agit de la même page, alors qu'en réalité la page a été en quelque sorte « récréée » sur le serveur (plus exactement, elle a provoqué le chargement d'une nouvelle instance de la page, dont les contrôles ont été automatiquement initialisés à partir des valeurs de la page précédente), avant d'être modifiée par l'appel de notre gestionnaire d'événement puis renvoyée vers le client.
Bref, un mécanisme un peu « magique » qui serait un peu long à détailler ici.mais qui ne fait appel qu'à du HTML standard et est étonnamment peu coûteux en matière de performances (j'en doutais au début.mais l'expérience m'a prouvé le contraire) grâce notamment au maintien en cache des pages compilées.
En résumé, fini le cruel dilemme entre l'interface Web exempte de coûts de déploiement, mais pauvre en fonctionnalités et l'interface « client-serveur » lourde à déployer, mais permettant une programmation orientée événement : ASP.NET a tiré le meilleur des interfaces classiques pour le mettre au service des développeurs Web qui peuvent maintenant avoir le beurre et l'argent du beurre !
II. Côté langage, il y en a pour tous les goûts▲
L'aspect « multilangages » de l'architecture .NET a été très largement mis en avant sans que son utilité me semble évidente dans un premier temps : c'est bien beau de pouvoir écrire des pages ASP.NET en Fortran ou en Cobol, mais franchement, y a-t-il beaucoup de développeurs qui utilisent cette fonctionnalité ?
Néanmoins, il faut avouer de ce support multilangage est une aubaine, dans le sens où il permet à chaque développeur ASP.NET de se concentrer sur la technologie plutôt que sur l'apprentissage d'un nouveau langage : venant du C++, je me suis naturellement tourné vers C# tandis que des collègues adeptes de VB ont naturellement penché vers VB.NET et le plus beau dans tout ça est qu'on peut sans problème faire cohabiter des pages rédigées dans des langages différents dans la même application.
Ceci sonne le glas de la ségrégation chez les développeurs : fini le temps où seuls les c'est-à-dire hors du C++ étaient les seuls habilités à faire des appels alambiqués à l'API Win32, tandis que les pauvres développeurs Web souffraient des limitations des langages de script ! Désormais, tout le monde profite de la performance et la robustesse apportée par les langages .NET (compilation des pages, typage fort, gestion des exceptions, héritage) et tout le monde a accès aux mêmes classes de la bibliothèque .NET.
Effet secondaire appréciable : les compétences acquises dans le développement d'applications ASP.NET peuvent très largement s'appliquer à des applications Windows Forms et vice-versa.
III. Plus besoin d'IIS, SQL Server ni de Visual Studio pour démarrer▲
Arrivé à ce stade, vous vous dites peut-être « c'est bien beau tout ça, mais il me faut la grosse artillerie pour démarrer : ça ne marche qu'avec IIS et SQL Server et Visual Studio.NET ».
Et bien, la réponse est non ! Vous pouvez très bien développer vos premières applications ASP.NET en utilisant uniquement des outils disponibles en téléchargement gratuit le site http://www.asp.net/ Lien non Microsoft : le kit de développement .NET, la base de données MSDE (une version légère de SQL Server) et l'environnement de développement Web Matrix, qui inclut un petit serveur HTTP qui vous évite d'avoir à installer IIS sur votre machine.
Ce trio est largement suffisant pour démarrer, tester, évaluer, créer vos premières applications ASP.NET en vous inspirant par exemple des Starters Kits (un ensemble de squelettes d'applications : site portail, site e-commerce, site communautaire.).
Vous pouvez même héberger gratuitement le résultat de votre travail sur http:/france.webmatrixhosting.net Lien non Microsoft, un service qui propose 20 Mo d'espace disque et 10 Mo sur une base SQL Server, au sein d'une infrastructure dont j'ai pu apprécier la disponibilité et la performance.
IV. Un mode de déploiement radicalement simplifié▲
Puisqu'on parle d'hébergement, j'aimerais profiter de l'occasion pour souligner une autre évolution radicale d'ASP.NET : la simplification du déploiement.
Souvenez-vous des galères du déploiement des sites ASP : tant qu'il s'agissait de copier des pages « .asp » sur le serveur de production par FTP, ça allait.mais lorsqu'il fallait déployer des composants COM, ça se compliquait.à moins d'avoir la chance d'avoir entièrement la main sur le serveur distant, il fallait contacter un administrateur (généralement injoignable) chez l'hébergeur, pour lui demander d'installer les composants COM et les inscrire dans le registre, ce qui comportait d'ailleurs parfois des risques de conflits de versions.
L'architecture est totalement repensée sur ce point : chaque application ASP.NET dispose de son propre répertoire \bin dans lequel seront déposés les composants binaires utilisés (assemblages), par simple copie de fichier, sans besoin de l'intervention d'un administrateur.sans parler des possibilités de faire cohabiter plusieurs versions ou encore de modifier des paramètres de configuration (comme la durée par défaut d'une session utilisateur) sans redémarrer le serveur, ni même IIS !
V. Enfin de vrais composants graphiques réutilisables !▲
Un des aspects frustrants du développement ASP ou PHP, surtout pour les développeurs objets habitués à plus de confort, est l'impossibilité de pouvoir encapsuler « proprement » des éléments graphiques : nous avons tous développé des « librairies de scripts cracheuses de HTML », capables de générer des tableaux liés à des données, des en-têtes, pieds de page ou autres barres de menus afin d'essayer de ne pas avoir à écrire deux fois la même chose (la paresse rend intelligent, c'est bien connu !). Néanmoins, il faut reconnaître qu’il s'agissait là d'un ersatz d'encapsulation et que la partie de jonglage avec les instructions < !--Include .> se terminait fréquemment par des collisions de variables !
Désormais, l'architecture ASP.NET propose le mécanisme des « contrôles » qui permet véritablement d'encapsuler des éléments graphiques sous la forme de composants réutilisables et paramétrables : vus comme des objets par le développeur, ils sont transformés en HTML standard lors de la génération de la page.
Parmi la collection de contrôles fournis en standard avec ASP.NET, citons par exemple le DataGrid qui permet, en quelques lignes de code, d'afficher le contenu d'une source de données sous forme d'un tableau HTML formaté incluant optionnellement un mécanisme de pagination ou les contrôles de type Validator qui offrent un très large choix pour la validation de saisies utilisateur, avec adaptation automatique aux possibilités du navigateur.
De plus, l'utilisateur a la possibilité de créer très facilement ses propres contrôles, en encapsulant des morceaux de page (par exemple : un pied de page ou une barre de menu) au sein d'un contrôle dit « utilisateur ».
En résumé, une page ASP.NET se conçoit comme un assemblage d'éléments graphiques et non plus comme un flot de HTML, pour le grand bonheur du développeur qui augmente drastiquement sa productivité en recourant des composants réutilisables.
VI. En conclusion▲
J'espère au moins vous avoir convaincu qu'ASP.NET est vraiment une évolution majeure dans les technologies de développement Web, basée sur une architecture totalement novatrice.
À ce titre, ASP.NET mérite au moins d'être testée, ne serait-ce que par souci de veille technologique.et ceci est d'autant plus facile que vous pouvez télécharger gratuitement sur http://www.asp.net/ tout ce qu'il faut pour démarrer !
Je pense en revanche qu'il y a un point sur lequel je ne pourrai pas vous convaincre : abandonner ASP.NET lorsque vous y aurez goûté.