Asp.Net tue le programmeur web


En premier lieu je tiens à mentionner que je ne suis pas contre le Asp.Net.
Je programme depuis des années en Asp.Net/C# et j’adore ça.

Par contre, j’ai eu la chance, et oui je dis bien « la chance »,
de commencer le développement web en ASP 3.

L’idée d’écrire cet article me vient du fait que j’ai reçu quelques questions telles que :

  • Comment fait-on pour accéder à une variable du code-behind en javascript?
  • Pourquoi je perds la valeur de mes variables du code-behind suite à un post-back?
  • (D’un programmeur Asp.Net qui a du faire de la maintenance sur du ASP 3) Comment je fais un « validateur »?

En plus, je vous suggère de demander à un programmeur Asp.Net

  • Quel est la différence en GET et POST?
  • Qu’est-ce que la balise <select ...>?
  • Qu’est-ce que l’évènement submit en html?

… il ne devrait pas avoir beaucoup de réponse.

Ce qui m’a fait réaliser que beaucoup de programmeurs ont fait du développement
web seulement avec Asp.Net et beaucoup parmi eux ne connaissent pas vraiment le
principe du web. Donc je me suis dit que je devais mettre en garde les programmeurs
dont leur seule expérience web est le Asp.Net.

D’abord, je tiens à clarifier que le web n’est rien d’autre qu’une requête TEXTE
qui est envoyée d’un client à un serveur et le serveur renvoie une réponse TEXTE
qui est interprétée par le client. Une fois que vous avez bien compris ce concept, il sera
beaucoup plus facile de faire du bon développement web. Ça semble si simple et pourtant…

Asp.net a su abstraire cette notion de façon assez efficace. Et comment il le fait :

Le fameux viewstate

Je dois reconnaître que grâce au viewstate et les nombreux contrôles
de Asp.Net il est très rapide de concevoir un formulaire. Pour récupérer l’information
il suffit de faire

	
		myTextbox.Text;
		myDropDownList.SelectedValue;
		myCheckBox.Checked;
	

Par contre en HTML ces contrôles n’existent pas (je viens sûrement d’en surprendre plusieurs),
du moins pas de la manière dont Asp.Net nous les présentent. Je ne vais pas écrire
les bons et mauvais côtés du viewstate, car ce n’est pas le but
de cet article. Grâce au viewstate et les contrôles Asp.Net
beaucoup trop de programmeurs ne se posent pas la question : Qu’est-ce que ce contrôle
génère coté client?
. En fait, plus souvent qu’autrement, ces contrôles génèrent
plus de texte qu’on en a besoins, en plus ils augmentent le viewstate.
Je le sais, car quand j’ai commencé avec Asp.Net je suis tombé dans le piège.

En Asp.Net tout est un POST

Tout post-back est fait avec la méthode HTTP
POST. C’est à dire : le OnClick sur n’importe quel contrôle Asp.Net, le
sort ou le PageIndexChange pour un DataGrid ou
GridView bref environ tout évènement Asp.Net. Le problème est que le
POST en HTTP est plus lourd que le GET et surtout ils n’ont pas la
même fonction.

GET : C’est la méthode la plus courante pour demander une ressource.
Une requête GET est sans effet sur la ressource, il doit être possible de répéter la
requête sans effet.

POST : Cette méthode doit être utilisée pour ajouter une nouvelle
ressource (un message sur un forum ou un article dans un site).
L’URI fournie est l’URI
d’une ressource liée à la nouvelle ressource (comme l’URI du forum ou site)
et non l’URI de la ressource nouvellement crée.

source :

Wikipedia 
http://fr.wikipedia.org/wiki/Hypertext_Transfer_Protocol

Asp.Net utilise de façon assez abusive le POST. Le problème, encore une fois,
c’est qu’aucun programmeur Asp.Net ne va se poser la question :
Est-ce que j’ai besoin du GET ou du POST?.
Effectivement qu’ils ne se posent pas la question, ils ne peuvent même pas contrôler
ce qu’ils utilisent.

Asp.Net = développement rapide d’application… vraiment ?

Un autre grand problème est qu’il peut être difficile de créer certaine interface
en Asp.Net alors qu’il est si facile de le faire directement en HTML. Par exemple,
faire une liste de boutons radio à l’aide d’un Repeater.
Je sais que le RadioButtonList existe mais parfois le Repeater
est plus pratique. De base il est impossible de faire fonctionner la liste de boutons radio
avec le Repeater. Si on cherche sur Internet, la solution la plus fréquente
est d’utiliser du javascript. Tant qu’a moi la solution la plus simple est d’inscrire directement
dans le Repeater : <input type=radio name=myRadio value=... />
afin de créer la liste de boutons de radio. Ensuite pour récupérer la valeur du bouton sélectionné
il suffit de faire Request.Form["myRadio"]. Ceci est l’équivalent de faire du bon
vieux développement web.

En fait, il suffit de générer du texte qui, côté client, est interprété soit comme du HTML,
du javascript ou simplement des données qui serviront à faire du Ajax. L’idée est que c’est
seulement du TEXTE.

En résumé, je ne dis pas de ne plus utiliser les contrôles Asp.Net car il est vrai que ces
contrôles accélèrent le développement, mais de se poser la question Est-ce que j’ai vraiment
besoins d’un contrôle Asp.Net? Serait-ce plus simple d’écrire directement du HTML?
.

Voici quelques réflexions :

Est-ce que le asp:HyperlinkField ou le asp:LinkButton est vraiment
nécessaire? Ou il est possible simplement de faire
<a href="lapage.aspx">Le page</a>.

Au lieu de créer une page avec beaucoup de asp:Panel peut-être qu’il serait
mieux de créer plusieurs pages qui seront plus légères.

Le GridView (ou DataGrid) est lourd, peut-être il
serait mieux d’utiliser le Repeater. Pour afficher une liste de texte
il peut être utile d’utiliser le BulletList.

Le asp:Label est très utile mais parfois il est plus utile de faire
<%= UneVariableProtectedProvenantDuCodeBehind %> directement dans la page .aspx

Le meilleur truc :

Pour ceux qui ont seulement programmé avec Asp.Net apprenez ASP 3 ou PHP, tenter de
reproduire le principe d’un DataGrid avec pagination, ordonnancement et recherche
et faites un formulaire avec des validations. Après avoir fait ce travail vous
pourrez vous considérer un vrai programmeur web.

Liens d’intérets

,

  1. #1 by Samuel Sirois on 17 mars 2009 - 8 h 34 min

    Merci de mettre en lumière cette problématique!

    J’ai également été en mesure de constater cette incompréhension du Web, du protocole HTTP et du réseau Internet chez beaucoup de nouveaux programmeurs Web. L’avenir, c’est le Web! Le marché demande à beaucoup de programmeurs de passer d’une architecture classique de développement (Unix, GNU/Linux, Windows) à une plateforme qu’ils ne connaissent pas : l’Internet et son protocole de diffusion, le HTTP.

    Par paresse, par écoeurement de se faire imposer cette nouvelle plateforme à la mode, par désintérêt ou par snobisme, plusieurs ne feront pas l’effort de comprendre la plateforme sur laquelle ils doivent dorénavant travailler. Peut-on les blâmer alors que ASP.Net vient abstraire – plus ou moins efficacement selon le cas – toute la plateforme? Au moins, un développeur ASP.Net a cette couche d’abstraction sur laquelle il peut lancer le blâme… J’ai vu ces mêmes questions sur les différentes méthodes HTTP chez des programmeurs PHP qui n’ont pas cette défaite et qui devraient connaître les rouages de leur plateforme de développement.

Les commentaires sont fermés.