DotNet Is Not Dead !

John Sprunger a rédigé, dans un de ses billets, un ensemble de bonnes pratiques qu’il a amassé au cours de son expérience avec les WebForms.

Avec sa permission, voici la traduction de son billet original :

— Début de la traduction —

Au fil du temps tout en utilisant ASP.NET j’ai collecté un assez bon ensemble de bonnes pratiques que je tente de mettre en place sur mes projets – la plupart d’entre eux sont des choses qui permettront de simplifier l’expérience de développement avec ASP.NET, des solutions aux problèmes communs, ou des astuces qui vous rendront simplement la vie plus facile. La plupart de ces bonnes pratiques ne sont applicables qu’aux WebForms, mais certaines sont applicables à ASP.NET MVC aussi.

1. Ne pas écrire du code. NET directement dans votre balisage ASPX (sauf si c’est pour du databinding, c’est à dire des déclarations Eval). Si vous avez également un code-behind, le code de votre page sera dispersé à plusieurs endroits, rendant celui-ci moins gérable. Mettez le code. NET dans votre code-behind. Les choses peuvent très rapidement devenir complexes et difficiles à déboguer quand vous verrez le code s’exécuter à deux endroits différents.
2. SessionPageStatePersister peut être utilisé en conjonction avec le ViewState pour rendre celui-ci utile sans augmenter les tailles des pages. Redéfinir le PageStatePersister de la Page avec un nouveau SessionPageStatePersister va permettre de stocker toutes les données du ViewState en mémoire, et ne stocker qu’une clé chiffrée sur côté client. Cela rendra vos pages plus petites et seront téléchargées plus rapidement si vous avez beaucoup de données dans le ViewState pour une raison quelconque, mais il augmentera votre utilisation de la mémoire sur le serveur – donc à utiliser avec précaution. Voir l’exemple ci-dessous pour savoir comment utiliser le SessionPageStatePersister.

   public override PageStatePersister GetStatePersister() {
   	return new SessionPageStatePersister(this);
   }

3. Créez une BasePage et faites en hériter vos pages afin de réutiliser le code commun. Simples principes de conception orientée objet – si vous avez des fonctions communes entre les pages, comme la gestion de la sécurité par exemple – les mettre dans une classe de base qui hérite de System.Web.Page, et faites que vos pages héritent de cette page de base.
4. Créez une MasterPage pour vos pages pour l’héritage visuel. N’utilisez pas de server-sides includes ASP. Les pages avec des styles visuels très différents devraient utiliser une MasterPage différente. N’utilisez pas une MasterPage pour de l’héritage de code.
5. Utilisez le cache fournit par ASP.NET afin de mettre en cache les informations fréquemment utilisée de votre base de données. Développez (ou réutilisez) une couche de cache générique qui encapsulera le cache ASP.NET. Si vous récupérez la même liste de la base dans une liste déroulante à chaque fois qu’une page se charge, vous devriez récupérer cette liste à partir du cache et le paramétrer en fonction de votre besoin.
6. Encapsulez les objets enregistrés dans le ViewState avec des propriétés sur vos pages afin d’éviter les erreurs d’orthographe lors du développement, etc. lorsque vous référencez des éléments de la collection ViewState. Par exemple, vous ne devriez avoir ViewState[ "key"] qu’une seule fois dans votre page par propriété. Voir l’exemple ci-dessous.

   private int SampleId
   {
   	get { return ViewState["SampleId"] == null ? 0 : (int)ViewState["SampleId"]; }
   	set { ViewState["SampleId"] = value; }
   }

7. Évitez de mettre de gros objets et graphes d’objets dans le ViewState, utilisez le principalement pour stocker des identifiants ou des objets DTO très simple. C’est la raison pour laquelle les gens se plaignent toujours d’un ViewState énorme – ils stockent des choses comme des DataSets dans le ViewState (mauvaise idée). Si vous vous cantonnez a de petits objets avec un nombre limité de propriétés ou tout simplement des identifiants sous forme d’entiers, les données de votre ViewState ne seront pas ingérable et dans ce cas, le ViewState est tout à fait utilisable.
8. Encapsulez l’objet Session ASP.NET avec une classe SessionManager afin d’éviter les erreurs d’orthographe lors du développement, etc. lorsque vous référencez des éléments de la collection Session. Juste une autre façon de limiter les erreurs simple de développement.
9. Utilisez abondamment les valeurs de configuration avec les applicationSettings key/value dans le web.config – encapsulez la classe Configuration.ApplicationSettings avec une classe qui peut être utilisée pour récupérer facilement des paramètres de configuration fortement typés sans avoir à mémoriser les clés dans le web.config. Si vous avez des paramètres, comportements, etc. qui ont besoin de changer entre les différents déploiements de votre application, ceux-ci devraient être contrôlés via des paramètres dans le web.config. Par exemple, on nous demande souvent « Nous voulons que la fonctionnalité X soit active à la fin du mois » – donc développez, testez et déployez la mise à jour à l’avance. Mais, ajoutez une valeur dans le web.config qui contrôle si oui ou non la fonction doit s’afficher c’est-à-dire FeatureXEnabled= »False », et le jour J allez le changer à « True ».
10. Evitez la facilité en définissant les propriétés d’affichage sur vos contrôles d’interface utilisateur, au lieu de ça utilisez les styles CSS et des classes – ce qui rendra vos styles plus gérable. Juste une bonne pratique de développement web en général.
11. Créez des UserControls au sein de votre application afin de réutiliser les fonctionnalités communes liées à l’interface utilisateur au travers de vos pages. Par exemple, si une liste déroulante contenant une collection de catégories sera utilisée à plusieurs endroits dans le site – créez un contrôle CategoryPicker qui se liera lui-même aux données quand la page sera chargée. Il s’agit de la bonne pratique #1 qui me fait gagner le plus de temps, et pourtant je suis toujours surpris de voir combien souvent je vois la même liste déroulante avec les mêmes données utilisée de la même façon sur 20 pages différentes – et aussi la même logique de liaison de données non typée en double 20 fois!
12. Utilisez des Propriétés sur vos UserControls pour configurer des choses comme les valeurs par défaut, un affichage différent entre les pages, etc. Les propriétés de type valeur peuvent être définies dans votre UserControl et ensuite être spécifié dans votre balisage ASP.NET en utilisant les propriétés définies au niveau de la classe sur les UserControls. Il s’agit d’une excellente façon d’augmenter le découplage en dehors de réutiliser vos UserControls – attention cependant à la complexité de la logique de votre UserControl qui augmente.
13. Utilisez les contrôles de validation ASP.NET pour effectuer les validations simples, et utilisez le CustomValidator pour effectuer des validations complexes.
14. Créez une page qui gère les erreurs d’une façon conviviale pour l’utilisateur sur laquelle on peut être redirigé quand une quand une exception non gérée se produit au sein de votre site Web. Loguez toutes les exceptions qui arrivent sur cette page. La redirection peut être effectuée via l’événement Page_Error dans votre page de base, l’événement Application_Error dans votre Global.asax, ou dans la section liée au traitement des erreurs dans le web.config. Fondamentalement, selon la méthode que vous adopterez – assurez-vous de ne pas laisser disparaître toute exception non gérée ou non loguée!
15. Lorsque vous travaillez avec des pages qui utilisent des affichages dirigés par des données hautement dynamiques, utilisez le composant (gratuit) DynamicControlsPlaceholder créé par Denis Bauer afin de simplifier le code nécessaire pour sauvegarder l’état de contrôles ajoutés dynamiquement entre les postbacks. Ce petit contrôle m’a permis de sauver d’innombrables heures de souffrance dans la création de pages avec des UserControls très dynamiques. Un truc – si vous utilisez la gestion des événements délégués dans un UserControl, vous devez les rebrancher à PostBack, c’est un peu sale mais ce n’est pas un gros problème le plus souvent. Les gestionnaires d’événements sont le seul «État» qui n’est pas enregistré entre les PostBacks si vous utilisez ce contrôle.
16. Désactivez le ViewState des contrôles et UserControls qui n’en ont pas besoin.

— Fin de la traduction —

En espérant que ces bonnes pratiques vous aide !

PS : si la traduction est incorrecte à certains endroits, n’hésitez pas à me le signaler, je ne suis qu’un développeur =)

Lors de la PDC 2009 qui s’est déroulé à Los Angeles cette année, Microsoft a annoncé que le développement d’Internet Explorer avait commencé depuis quelques semaines. L’accent a été mis sur le respect des standards, notamment sur HTML5 et CSS3.

Microsoft a aussi annoncé qu’Internet Explorer 9 allait tirer parti de la puissance du GPU (chipset graphique), grâce à technologie D2D de DirectX (présente dans Windows Vista et Windows 7).

Le gain de performance est ainsi surprenant comme le montre cette vidéo (en anglais) où des services comme GoogleMaps ou BingMaps seront étonnamment fluides. Les développeurs pourront ainsi profiter de cette puissance de façon transparente en continuant à suivre les bonnes pratiques d’utilisation des standards comme ils l’ont toujours fait (ou du moins certains).

Microsoft à aussi mis l’accent sur l’amélioration des performance du moteur Javascript, mais pas seulement. En effet, l’équipe de développement a analysé le comportement des sites actuels variés afin de savoir quelles couches étaient le plus sollicité, comme l’exécution des script ou bien le rendu de la page. L’image ci-dessous présente les résultats de cette analyse, on peut ainsi se rendre compte que le comportement du navigateur va différer selon le site et la façon dont il a été conçu (application RIA ou bien simple site internet).

Le moteur d’exécution Javascript n’est donc pas le seul point sur lequel il faut se concentrer si l’on souhaite augmenter les performances globales de la navigation offerte à l’utilisateur, ce n’est qu’une des briques du système.

Malgré tout, Microsoft n’a pas négligé ce moteur d’exécution Javascript et prouve qu’il est sur la bonne voie en se rapprochant de très près aux autres concurrents que sont Firefox, Chrome et Safari dans leurs versions les plus avancées au test « SunSpider » de l’équipe Webkit d’Apple. On voit notamment l’amélioration par rapport à IE 7 et IE 8.

Le test Acid3 a aussi été exécuté en direct, montrant un résultat de 32/100, ce qui est nettement mieux que le score obtenu avec IE 8 qui était de 20/100. Même si les résultats ci-dessous montrent une nette augmentation, il n’en reste pas moins que IE 9 est encore loin derrière ses concurrents qui atteignant les 100/100 pour Safari, Opera et Chrome et dépassant les 90/100 pour Firefox.

Toujours est-il que cette version est à peine commencée qu’elle obtient des performances non négligeables.

Les bases sont posées, ainsi que la volonté de Microsoft de respecter au mieux les standards, et de proposer un navigateur aussi performant que ceux des concurrents.

Arrivera-t-on un jour à faire que le rêve de tout développeur web devienne réalité ? A savoir : ne plus avoir à tester son application sous plusieurs navigateurs. C’est en tout cas ce que Microsoft nous promet avec cette nouvelle mouture et les suivantes.

PS : Le plus surprenant dans tout cela est peut-être qu’un exécutif (Steven Sinofsky, président de la division Windows et Windows Live de Microsoft, qui a présenté ce keynote) s’est risqué de faire les tests en direct devant une foule d’experts, démontrant ainsi l’engagement de Microsoft envers le respect des standards et l’orientation qu’ils souhaitent adopter avec la version 9, qui vient continuer la petite (r?)évolution de IE 8.

Sur le projet sur lequel je travaille actuellement, j’ai eu à utiliser JQuery pour sauvegarder la valeur sélectionnée d’un RadioButtonList lorsqu’elle changeait du côté client.
« Rien de plus simple » me direz-vous ! En effet, dans la plupart des cas c’est direct : il suffit d’ajouter un handler à l’évènement « change » du contrôle que l’on souhaite « monitorer ».

Prenons l’exemple d’un TextBox :

Déclaration du contrôle :

<asp:TextBox ID="nom" runat="server"></asp:TextBox>

Ajout du handler sur l’évènement « change » avec JQuery :

$("#<%= nom.ClientID %>").change(function(){
	var nom = $(this).val();
	//logique métier
});

La ou ca se complique c’est lorsque on essaye de « monitorer » un liste de boutons radio (contrôle RadioButtonList) :

Déclaration du contrôle :

<asp:RadioButtonList ID="yesNoRadio" runat="server">
	<asp:ListItem Value="False" Selected="True" Text="Non"/>
	<asp:ListItem Value="True" Text="Oui"/>
</asp:RadioButtonList>

Ajout du handler sur l’évènement « change » avec JQuery :

$("#<%= yesNoRadio.ClientID %> input[name='<%= yesNoRadio.UniqueID %>']").change(function() {
	var yesNoRadioValue = $(this).val();
	//logique métier
});

Dans ce cas, on voit que pour « monitorer » une liste de boutons radio, il faut spécifier l’attribut « name » qui est le même au sein d’un groupe de boutons radio,
et ajouter un handler à l’évènement « change » sur les éléments retournés par JQuery.

Maintenant, lorsqu’on clique sur un autre bouton radio, on déclenche la fonction de monitoring.

Finalement, ce n’était pas très dur et on s’attendait quand même à un piège. Justement, ce qu’il faut savoir c’est qu’IE, comme à son habitude fait des siennes, et que lorsqu’on clique sur le bouton radio la fonction n’est pas déclenchée.
En fait, elle n’est pas déclenchée immédiatement, mais lorsqu’on on perd le focus sur le bouton radio nouvellement sélectionné, c’est à dire sur l’évènement « blur ».
Ce n’est pas forcément génant si on sauvegarde juste la valeur pour un traitement différé (callback ajax ou autre), mais si on souhaite alerter l’utilisateur lorsqu’il clique sur le bouton, c’est rapé, il recevra l’alerte une fois l’évènement « blur » détecté, c’est à dire lorsqu’il aura cliqué ou naviqué autre part sur la page. Comportement qui peut paraître très bizarre aux yeux d’un utilisateur.
La solution est alors de déclencher l’évènement « blur » nous même en réponse à l’évènement « click » puis de redonner directement le « focus » au bouton radio :

// Hack IE pour déclencher l'évènement "change" lorsqu'il change réellement et non lorsque l'évènement "blur" intervient
if ($.browser.msie) { // Notez l'utilisation en JQuery pour détecter le navigateur utilisé
	$("#<%= yesNoRadio.ClientID %> :radio").click(function() { // On déclare le handler pour chaque bouton radio de la liste
		this.blur();
		this.focus();
	});
}

La solution finale :

<asp:RadioButtonList ID="yesNoRadio" runat="server">
	<asp:ListItem Value="False" Selected="True" Text="Non"/>
	<asp:ListItem Value="True" Text="Oui"/>
</asp:RadioButtonList>

$("#<%= yesNoRadio.ClientID %> input[name='<%= yesNoRadio.UniqueID %>']").change(function() {
	var yesNoRadioValue = $(this).val();
	//logique métier
});
if ($.browser.msie) {
	$("#<%= yesNoRadio.ClientID %> :radio").click(function() {
		this.blur();
		this.focus();
	});
}

En espérant que cela vous aide.

Voici une liste impressionnante d’utilitaires qui rendent la vie d’un développeur (sous Windows) beaucoup plus facile. C’est en anglais, mais merci à Scott Hanselman qui vient de rendre ma vie de développeur beaucoup plus facile !

Voila une série d’articles très intéressants écrits par Scott Guthrie sur ce qu’apporte Visual Studio 2010 en terme de nouvelles fonctionnalités, ainsi que sur le Framework .NET 4.0.

Voici une petite vidéo pour vous montrer là ou je vais habiter bientôt :

Oyez, Oyez !

Aujourd’hui est un grand jour ! Nous venons de finir les derniers préparatifs pour le lancement de ce blog. Tout le personnel est en place pour vous accueillir et faire en sorte de vous mettre à l’aise…

Ici, vous pourrez trouver toute une panoplie d’articles et de photos dédiées à cette merveilleuse province : le Québec.
Mais ce n’est pas tout !
Vous trouverez aussi tout plein d’articles traitant d’un sujet sensible, la technologie asp.net, tant novatrice ! En effet, les bienfaits sont encore méconnus de la plupart des développeurs, même des plus azerty !

N’attendez plus, et entrez dans mon (futur) monde.

PS : le module ouverture d’esprit 2.0 est requis pour visualiser correctement ce blog.
PS2 : Merci Katia pour m’avoir aidé indirectement a trouver un nom à ce blog !