|
La question revient
souvent : quelle technologie adopter pour interfacer une base de
données avec un site Web ? Bien qu'ayant délibérément pris le
virage ASP, notre expérience passée nous permet d'en comparer les
avantages et les inconvénients avec une autre technologie, fort répandue
sur le Web elle aussi : Perl.
Mettre en place une
site interactif avec une base de données nécessite deux analyses préalables.
La première consiste à considérer le temps et la facilité de développement,
la seconde reposant sur l'exploitation proprement dite, et plus précisément
sur la fiabilité du système en ligne ainsi que l'utilisation hors
ligne des données.
Côté développement,
les deux langages ont bien sûr leur propre syntaxe, et il est bien
difficile de les départager, la notion de familiarisation intervenant
grandement dans ce genre de considération. Si nous notons que de
nombreux programmeurs débutants ont pu rapidement commencer à développer
des applications ASP,
ceci est tout aussi vrai pour Perl.
Toutefois, et en toute subjectivité, le non-développeur que j'étais
a remarquablement galéré avec Perl
et s'est, en revanche, très vite adapté à ASP.
Mais je le dis bien, c'est en toute subjectivité...
L'un des inconvénients
majeurs de Perl,
côté développement, réside dans le fait qu'il est nécessaire de définir
dans le script la structure de la base de données qui va être
exploitée. Si cela est un jeu d'enfant pour un développeur expérimenté,
le néophyte en revanche risque dans bien des cas d'y perdre
rapidement son latin. Sous NT/ASP, le simple fait de se connecter à
la base de données (Access,
SQL Server,
Oracle,
etc.) suffit à ce que la structure de la base soit comprise par
l'environnement de développement.
Du point de vue
de l'exploitation, d'aucuns diront que les solutions Unix
et dérivées (Linux,
Free BSD,
Zeus Solaris
etc.) sont plus fiables. Nous n'entrerons pas dans le débat du choix
de la plate-forme, mais nous contenterons de rapporter ici des faits
concrets constatés par nos propres expériences.
Notamment,
l'exploitation d'une boutique de 3.000 articles, et qui réalisait un
trafic d'environ 30.000 pages vues par mois, n'a pas tenu le choc sous
Perl :
le script, pourtant très bien développé et fort réputé (Shopping
Cart de Todd
Hassan Consulting),
monopolisait le CPU, entraînant de très forts ralentissements, voire
des pannes. Redéveloppée sous ASP,
et reposant pourtant sur une base Access
(connue pour ne pas très bien supporter les forts trafics), cette
boutique comporte désormais 15.000 articles, réalise un trafic de
250.000 pages vues par mois, et ne pose plus aucun souci technique.
La raison ? ASP
permet, entre autres, de continuer à tracker le visiteur
(indispensable pour la gestion d'un panier de commandes) sans
obligatoirement rester dans un environnement scripté. On peut donc à
loisir utiliser des pages HTML classiques sans rien perdre de la
commande en cours. Extrêmement pratique, et c'est autant d'économie
réalisée sur la charge du CPU.
En revanche, il
est à noter que la portabilité d'ASP est inférieure à celle
d'autres solutions. S'il existe des environnements ASP pour les
plate-formes Unix,
notons que celles-ci manquent encore cruellement de fiabilité et de
fonctionnalités. ASP est donc à déconseiller fortement à ceux qui
envisageraient une migration ultérieure vers Unix.
Conclusion :
en fait, pas de conclusions :-))) Ces quelques lignes n'ont pour seul
but que de vous faire partager un peu d'expérience personnelle. Notre
choix de la technologie ASP s'est fait sans doute en partie en raison
de notre culture Windows,
mais aussi de par, disons-le, la très grande facilité avec laquelle
ASP permet d'exploiter des bases de données sur le Web. Notez qu'il
existe des solutions alternatives telles PHP
ou ColdFusion,
que nous n'avons pas abordées ici, juste histoire de ne pas parler de
technologiques que nous n'avons pas eu l'occasion d'aborder.
|
