Pour ceux qui seraient intéressés, c’est déjà localisé en Français, et disponible ici:
http://msdn.microsoft.com/fr-fr/library/windows/apps/jj160316.aspx

Bonne lecture

Qu’est-ce que vous pensez de ce bout de code, et est-ce que vous pouvez deviner pourquoi il me donne des boutons ?

flag = hidValue.Value == "1" ? "F" :   

       hidValue.Value == "2" ? "Y" :    

       hidValue.Value == "3" ? "N" : null;

Y’a rien a gagner

La MSDN ne fournissant que des exemples du genre :

Je m’étais résigné à n’utiliser les initialiseurs qu’avec des constructeurs sans paramètres.

Alors qu’en fait, non, on peut tout à fait faire ceci :

Qui fonctionne très bien

…sous-entendu, le développeur lambda ne peut/veut pas comprendre l’intérêt d’utiliser, par exemple, un ORM, un framework IoC ou les principes SOLID.

Je ne reviendrais pas sur le sujet (déjà fait la dernière fois), mais Rob Conery (depuis peu parti de Microsoft) a pondu quelques billets très bien fichus sur l’intérêt d’utiliser un framework IoC, ou sur le mocking.

Alors, oui, c’est en anglais, mais c’est le prix a payer

200 Page Manual on Inversion of Control (plus or minus 199)
200 Page Manual on Inversion of Control, Part 2
Using Dependency Injection and Mocking For Testability

   1: HttpContext context = HttpContext.Current;

   2: LifeCycle lifecycle;

   3:  

   4: if (context.Session["CachedLifeCycle"] != null) {

   5:     lifecycle = (LifeCycle)context.Session["CachedLifeCycle"];

   6: } else {

   7:     lifecycle = Factory.GetLifeCycle();

   8:     context.Session["CachedLifeCycle"] = lifecycle;

   9: }

  10:  

  11: return lifecycle;

Genre…beaucoup…

Et du code comme ca, aussi (je simplifie :

   1: if (value == null){

   2:   message = "default";

   3: }else{

   4:   message = value;

   5: }

Et la, du coup, il a fallu sortir un coup l’artillerie pour faire rentrer tout le monde dans le droit chemin, a savoir, l’operateur ??

L’operateur ?? est un operateur qui renvoie, au choix, sa partie gauche si elle n’est pas nulle, et la partie droite sinon.

Donc, pour le second code, il permets de faire simplement :

   1: message = value ?? "default";

Le premier code est un peu plus compliqué, mais ?? va nous permettre de clarifier un peu tout ca aussi :

   1: HttpContext context = HttpContext.Current;

   2: LifeCycle lifecycle = (LifeCycle)context.Session["CachedLifeCycle"] ?? Factory.GetLifeCycle();

   3: context.Session["CachedLifeCycle"] = lifecycle;

   4:  

   5: return lifecycle;

Brownfield Application Development in .NET Kyle Baley and Donald Belcham Softbound print: December 2009 (est.) | 550 pages ISBN: 1933988711 Note : 5/5

Dès que le livre sort officiellement, je corrige toute info erronée, et ça part dans les critiques

Version Française

Ayant principalement travaillé avec le Framework .NET depuis bientôt huit ans (depuis la beta en 2001), j’ai régulièrement à intervenir sur des projets démarrés depuis un certain temps, et qui sont tranquillement, mais surement, devenu totalement impossible à maintenir.

La faute n’est en général pas liée au Framework en lui-même, mais à ce qui semble être une tendance naturelle de tout programme non trivial à dégénérer dans cet état.

Le livre « Brownfield Application Development in .NET » décrit un ensemble de pratiques qui peuvent permettre de sortir un projet de l’ornière, tout en diminuant le nombre de bugs, les problèmes de maintenance, et en améliorant la qualité du code.

Le livre est composé de deux grandes parties.

Il commence par décrire l’écosystème du projet, a savoir le contrôleur de code source, l’intégration continue, les métriques, et le suivi des bugs.

Il décrit ensuite comment améliorer la qualité du code en appliquant des fondamentaux de la conception orientée objet, tels que le découpage en couche, les principes SOLID, ou le découplage des dépendances,

Le livre s’attaque en suite a l’interface utilisateur, en la refactorisant vers le pattern MVP, puis explique comment introduire un ORM, ainsi  que ses avantages. La partie suivante est consacrée a une technique consistant a insérer une couche supplémentaire entre deux entités, de façon a créer une couche anti-corruption.

Enfin, il se termine en proposant un certain nombre de suggestions sur comment garder le rythme une fois que le projet est revenu a un état maintenable.

Ce que j’ai le plus apprécié dans ce livre, c’est qu’en plus d’être techniquement intéressant, il se paye le luxe d’être abordable a tout le monde (des développeurs juniors qui le liront d’une traite, aux plus senior qui y reviendront pour des points précis), et fun a lire.

De plus, les auteurs se montrent ouverts, et ne présentent aucune solution comme étant LA solution, préférant inviter le lecteur a sortir de sa zone de confort en présentant des solutions alternatives.

Au final, ce livre est un des meilleurs livres que j’aie lu ces dernières années sur le processus de développement, et qui a sa place sur les étagères de tout développeur qui doit assurer la maintenance d’une application…même si cette application lui appartient

English Version

Having worked for the better parts of the last eight years with the .Net framework, I am regularly called to work on a project started some times ago,
that quietly and slowly started to turn in an unmaintainable mess.

The fault, usually, is not limited to the framework, but seems to be a natural tendency for any non-trivial program to devolve into this state.

The book « Brownfield Application Development in .NET » explains the practices that may turn one of these projects back to a better health, with less bugs, less maintenance issues, and better code quality.

It firsts describes what should be the project ecosystem, starting from the version control, to continuous integration, automatic testing, quality metrics and defect tracking.

Then, it describes how to enhance the code quality by applying some OO fundamentals, like layering and dependency management.

After this, the book describes how to refactor from the usually entangled user interface code to a cleaner MVP pattern, how to abstract the data access code by using an ORM and how to prevent the code from corruption by adding an additional layer.

Finally, it ends by some suggestions on how to keep the project from returning to the brownfield state.

The best thing in this book is that it is really well balanced, fun to read, and accurate technically.

The authors also have an open point of view, not selling one solution as being the « true one and only » solution, but giving some advice, and challenging users assumptions all along.

All in all, it is one of the best books I have red in the last three years on development process and good practices, and it has its place on each developer that has to maintain an application…even if he is the one that developed it

La ou la formule est géniale, c’est que:
– Mardi, je trouve une erreur dans le livre
– Jeudi, l’auteur me réponds en vitesse pour me remercier (déjà, sympa de voir que non seulement les posts sont lus, mais en plus pris en compte)
– Mais le plus fort, c’est que je suis le blog de l’auteur depuis un moment, et que dans la foulée, il avait écrit un petit post sur le point en question’

Voila, personnellement, je trouve assez super niveau mentalité, et ouverture ]]> 0 https://blog.developpez.com/philippe/p8051/net/tester_les_exceptions_avec_nunit https://blog.developpez.com/philippe/p8051/net/tester_les_exceptions_avec_nunit#comments Fri, 11 Sep 2009 09:30:00 +0000 En ce moment, je suis en pleine session d’écriture de tests, et une chose en particulier me fait tiquer, a savoir les tests qui ne sont pas couverts a 100 %.

Dans le code en questions, les tests qui font baisser la couverture sont en général des tests qui concernent les exceptions.

On y trouve deux familles de tests, on a donc:

Le test « avec attribut » 

Ce test utilise l’attribut ExpectedException pour que le test fonctionne réussisse si et seulement si il jette un exception du type demande (ici, ArgumentOutOfRangeException). Le problème, en termes de couverture, est que tout le code situe en dessous de l’exception est ignore, le code n’est donc pas couvert a 100%.

Le test « traditionnel »

Si on n’utilise pas NCover, ou si on veut faire des tests sur le message retourné, on produit plus régulièrement de genre de code :

NB. : cet exemple vient directement du blog de NUnit, alors on peut admettre qu’il soit mentionné comme « bonne pratique »

Sauf que…

Sauf que si les tests fonctionnent correctement, une partie du code ne sera jamais atteinte, de même que si ils échouent.

Pourquoi ca pose problème ?

En général, je ne cherche pas a atteindre 100% de couverture…dans mon code testé ! Par contre, si une partie du code de test n’est pas joué, cela peut vouloir dire, au choix, deux choses :

1. Que le code testé est faux
2. Que le test est faux

Comment corriger les tests ?

Une option est de reprendre le code ci-dessus de la façon suivante :

Le catch sur une exception n’est plus présent…effectivement, mais de toute façon, si il n’est plus présent, le test va échouer quoi qu’il arrive…

Et selon vous, la couverture du code de test est-elle importante ? Cette méthode vous semble-t’elle valide ?

Apres pas mal de transpiration (premières lignes écrites en Décembre), voila un tutoriel sur l’utilisation de base de SubSonic (SubSonic, c’est bon, mangez-en )

L’article est présent ici :

http://philippe.developpez.com/articles/Subsonic/

Le bon coté,  c’est que maintenant que l’article est publie, je vais pouvoir parler un peu plus de SubSonic sur ce blog (avant, je n’avais pas de référence en français a fournir )

Maintenant, allez télécharger SubSonic, et commencez a travailler avec une DAL propre et facile a utiliser en moins de temps qu’il ne vous en a fallu pour lire ce post…

En effet, comme je le montrais (et si vous n’avez pas lu l’article, allez-y maintenant ), SubSonic peut se révéler très puissant pour travailler avec des opérations de type CRUD, ainsi que pour le mapping des objets de la base de données avec les objets .net, mais qu’en est-il des requêtes « tordues » ou « bizarres » avec lesquelles on est régulièrement forcé de travailler (et je ne vous parle pas des requêtes dont on hérite avec la maintenance d’une application vieille de quelques années :-/.) ?

Est-ce que je ne vais pas avoir aussi vite fait de tout me taper à la main ?

Dans les versions précédentes, on avait grosso modo deux choix :

1. Créer une vue ou une procédure stockée (en fonction de l’action), et appeler la vue ou l’action à partir de SubSonic
2. Avoir un moyen annexe pour « shooter » des requêtes directement dans la base (oui, un bon vieux select, avec un datareader, des dataset, des connections, t tout le toutim.)

Depuis la version 2, on à enfin un nouveau choix, plus « propre », et surtout plus rapide à mettre en ouvre, vous l’aurez deviné, l’objet InlineQuery.

En terme de code, il suffit de faire :

(Ceci est évidemment un exemple simpliste, mais c’est pour donner une idée).

Dans l’exemple du dessus, le @surname va permettre à SubSonic de créer une requête paramétrée directement. Si on avait voulu ajouter plus de paramètres, la fonction attends un tableau d’objets, on peut donc se lâcher ;).

InlineQuery propose aussi des méthodes renvoyant des DataReader, des DataSets, des scalaires (wow, un ExecuteScalar<T> ), et même un ExecuteTypedList, pour renvoyer une liste de T.

Voila, facile, pas cher, que du bonheur