I. Introduction

Pourquoi migrer de Asp à Asp .Net alors que tout va bien ? il y a plein de (fausses) bonnes raisons pour ne pas le faire. Tentons d'en démentir quelques unes.

II. Raison 1 : je n'ai pas envie d'apprendre le C# ou Vb .Net

On peut très bien faire du C# au "niveau 0", en pure procédural, avec des classes statiques.

On bénéficiera malgré tout du typage fort, de l'environnement de développement avec l'Intellisense.

III. Raison 2 : j'ai l'habitude d'écrire dans le flux de sortie pour créér tous mes contrôles

En Asp .Net il est très facile d'ajouter des contrôles dans d'autres contrôles, ou dans la page.

IV. Raison 3 : j'écris du codes JavaScript dans le flux, je ne pourrais plus le faire

Un contrôle "Literal" permet d'écrire ce qu'on veut où l'on veut dans la page, aussi crûment qu'avec un bon vieux Response.Write .

V. Raison 4 : je ne comprends rien au cycle de vie d'une page

De façon très résumé, voici le cycle de vie d'une page, dans l'ordre:

Execution de Page_Load : la page vient de se charger, on peut savoir si ce chargement correspond à un Postback. Ceci permet d'initialiser une seule fois les contrôles, les fois suivantes le ViewState se débrouille.

Execution des méthodes OnClick des contrôles : on peut gérer les actions de l'utilisateur, le chargement de la page n'est pas, fini.

Execution de Page_LoadComplete : on peut finir d'afficher sa page, en étant sur que les événements des contrôles on déjà été traités.

En résumé pour fair une analogie avec Asp 3.0 : Page_Load j'initialise mon formulaire, OnClick je traite comme si j'analysais mes Request.Form, Page_LoadComplete je finis l'affichage.

VI. Raison 5 : l'accès aux bases de données est trop compliqué

La plupart des bases de données fournissent un connecteur .Net.

Ces connecteurs permettent de récupérer facilement des résultats de requêtes scalaires, et des équivalents de RecordSet, en "lecture en avant seul" (DataReader), ou en "lecture avant/arrière" (DataSet).

L'usage est simple, l'accès aux colonnes se faisant par index ou nom de colonne, sans perdre ses habitudes favorites.

VII. Raison 6 : j'utilise le composant XY, je ne pourrais pas travailler sans

Le framework .Net intègre des éléments qui devaient être ajoutés (exemple : envoi de mails), de plus il existe beaucoup de composants tierces-partie pour .Net.

VIII. Raison 7 : les outils sont trops chers

Visual Studio Standard coûte au 26/08/2009 305€ HT, et Visual Web Developper Express est gratuit.

IX. Raison 8 : je développe plus vite des besoins urgents en Asp 3.0

Les classes existantes du framework, l'environnement de développement puissant, et le débuggeur pas à pas apportent une productivité bien plus grande, même si un temps d'adaptation est à prévoir.

X. Raison 9 : j'utilisais le composant XY pour produire des graphiques, il n'existe pas en .Net

Le framework 3.5 SP1 propose le composant MsChart, apte à répondre à tous les besoins de production de graphiques.

Il existe aussi des composants tierces-parties, payant, d'excellente qualité.

XI. Raison 10 : j'ai réussi à intégrer de l'Ajax dans mes pages Asp 3.0, je ne veux pas perdre ce développement

En Asp .Net, utiliser Ajax , ce n'est pas plus compliqué que de déposer un "ScriptManager" et "d'enrober" les contrôles à "ajaxer" dans un update panel.

XII. Conclusion

Changer de technologie, en passant de Asp 3.0 à Asp .Net, est une démarche qui peut être génératrice de stress et de crainte quand à sa pertinence.

Rien n'empêche une cohabitation Asp/Asp .Net, permettant une évolution vers un environnement de développement plus confortable, plus performant, et apportant un meilleur service à l'utilsiateur.