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à. oublié 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 terme 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é é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 !
Côté langage, il y en a pour tous les
goûts.
L'aspect " multi-langages " 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 multi-langage 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 cadors 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.
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/  : 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
, 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.
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 !
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 qui 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.
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.
A 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é
| 
