Un peu de retard dans mes blogs, mais pour tout vous dire, c’est que, suite aux TechDays, il y a tellement de nouveautés intéressantes à tester que je suis à fond dans Silverlight 4, EF4 et TFS 2010, alors les compte-rendus seront mis au propre un peu plus tard. Surtout que j’ai besoin de ces tests pour mon travail…
Par contre, je viens de finir le livre “Microsoft .NET : Architecting Applications for the Enterprise” (ISBN-13 : 978-0-7356-2609-6) de Dino Esposito et Andrea Saltarello, et je me permets de faire une critique de ce livre, qui contient de très nombreuses bonnes pistes, mais se limite parfois un peu trop à cause d’hypothèses discutables.
Structure du livre
Bon, autant vous le dire tout de suite, la première partie du livre (l’architecture aujourd’hui, UML, et les patterns) ne sert quasiment à rien si vous avez un minimum de connaissances en architecture de développement. C’est vraiment très introductif, avec une description de la différence entre un architecte et un développeur (qui tourne court, d’ailleurs), les bases d’UML (qui n’est pas du tout utilisé dans la suite du bouquin, à part pour les use cases), et enfin la notion de patterns. Honnêtement, toute cette première partie est uniquement de la quadricapillectomie, et semble avoir été mise dans le livre uniquement parce que l’éditeur considérait qu’il fallait 100 pages de plus sur le livre et qu’on ne pouvait pas attaquer sans introduction.
Le vrai contenu est la deuxième partie, et là, c’est enfin un livre d’architecture qui peut servir de référence pour des cas d’utilisations bien précis. En effet, cette deuxième partie est découpée selon les tiers applicatifs. Chaque chapitre reprend les différentes couches utilisables dans une application industrielle, et détaille les différents patterns architecturaux. La limite est que le livre ne prend pas d’initiative sur les bonnes pratiques : Esposito et Saltarello présentent bien sûr l’objectif de chacune des couches, mais à mon avis de manière trop orientée, et en sautant très vite aux mises en pratique les plus habituelles.
Exemple typique : dans l’introduction au tiers d’accès aux données, les auteurs sautent directement à la conclusion que la sérialisation doit se faire dans une base de données. Pourquoi se restreindre à cette hypothèse ? C’est vrai que c’est la majorité des cas, mais j’attendais d’un livre d’architecture qu’il se place à un plus haut niveau, en énumérant les objectifs de cette couche sans présupposer du moyen de les mettre en place, car immanquablement, des idées intéressantes se perdent. Pourquoi évacuer le stockage dans des fichiers ? Pourquoi évacuer les applications qui n’ont pas besoin de persistence ? Dans des articles précédents, je vous ai parlé de la prévalence. Ca peut être la réponse à des besoins particuliers, mais si on suit les auteurs, on ne risque pas d’y penser. Dommage… Mais ça n’enlève rien à la qualité des solutions proposées, même si elles ne sont pas toujours vulgarisées.
The Business layer
Le livre (ou plutôt la deuxième partie du livre) commence par une description complète du tiers Métier. Il détaille les patterns ActiveRecord, TableModule et les approches de type Modèle de Domaine, ainsi que le TransactionScript, dont je n’avais aucune idée de l’existence auparavant.
Ce chapitre a l’avantage de comparer ces différentes méthodes du point de vue de la productivité en fonction de la complexité de l’application, ce qui est très appréciable, la plupart des livres sur le sujet se contentant de décrire les patterns et de laisser au jugement du lecteur comment choisir. En particulier, à la page 143, vous trouverez un excellent graphique montrant la supériorité du Modèle de Domaine en termes de maintenabilité sur des grosses applications.
Bon, le bouquin est censé être générique sur .NET, mais il est édité par Microsoft, quand même ! Alors évidemment, quand on parle de TableModule, c’est bien entendu les DataSets typés ADO.NET qui sont présentés. Un peu plus loin, on a droit à une citation de Castle Project pour l’ActiveRecord, donc le livre n’est pas 100% orienté Microsoft. Mais dans l’ensemble, ne vous attendez pas à des exemples génériques.
The Service layer
A mon goût le plus lent au démarrage des chapitres de cette deuxième partie. Il met dix bonnes pages à décoller, avec une loooooongue introduction sur ce qu’est un service et comment le différencier d’un objet métier. Bon, si on n’a pas compris la différence, je crois qu’on ne comprend pas la notion même de tiers applicatifs, alors autant ne pas lire le livre, non ? C’est un reproche récurrent sur ce livre, pourtant très bon : par moment, il reprend les connaissances tellement à la base que ça ne sert à rien. La majorité du contenu n’est de toute façon accessible qu’à des gens qui ont déjà un peu d’expérience en architecture informatique, alors pourquoi expliquer des notions comme à des débutants ? Ils ne pourront de toute façon pas lire la suite…
Le livre expose clairement la problématique des DTO, à mon avis. En tout cas, sa conclusion me convient bien, car elle n’est pas dogmatique. Après avoir exposé le principal (et léger) défaut du livre, voici sa principale qualité de mon point de vue : il est très proche des préoccupations industrielles (et si vous m’avez déjà lu, vous savez à quel point je me méfie de tout ce qui est technologies ou documentations non applicables à mon métier). Sur les DTOs en particulier, pas de théorie sur l’utilité ou pas de cette technologie, pas d’idée tranchée sur la nécessité d’en utiliser un pour bouchonner chaque objet métier transporté, mais une approche pragmatique avec des recommandations pour savoir quand en utiliser ou pas, quels sont les avantages et les inconvénients, et surtout l’explication d’une approche mixte très intéressante. Bref, du vrai jus de cerveau de gens qui ont déjà monté beaucoup de vrais projets, et pas les recommandations strictes d’un éminent spécialiste refusant l’idée même d’une base de données qui ne suive pas toutes les règles de normalisation (c’est du vécu, là).
Une autre partie intéressante du deuxième chapitre sur le tiers Service est la description d’une architecture SOA, et la différence d’avec une simple couche de services, en particulier en termes de contractualisation, et de compatibilité par la notion de policies. J’ai rarement vu une explication aussi claire de SOA. Pour avoir mis en place une formation sur le sujet à destination de non-spécialistes, je sais que le sujet est difficile à encadrer clairement et ce livre y arrive à la perfection. Si je refais un jour cette formation, je changerai certainement ma façon de présenter SOA à la suite de ses enseignements.
The Data Access layer
Le chapitre sur les DAL est le plus fourni de tout le livre. Clairement, il y a de quoi dire, mais je pense que c’est aussi le cas pour le Métier ou la couche de services. Surtout que, contrairement aux précédents chapitres, le livre n’apporte pas sur cette couche une vue de haut niveau montrant des solutions différentes de l’archétype DAL avec le support du mutibase, etc.
Là où ça devient intéressant, c’est quand les auteurs recensent ce qui fait le DAL lui-même, car c’est vrai que la réalisation est parfois très dur à démêler du métier, en particulier quand on commence à utiliser des procédures stockées avec du métier, par exemple. Du coup, la clarification sur les responsabilités du DAL est la bienvenue, avec le support des transactions et de la concurrence comme axes principaux. Ce genre de présentation permet de renouer avec d’autres technologies que la base de données, même si le livre ne le fait pas. En tout cas, personnellement, cela m’a permis de valider que du point de vue structurel, un module de prévalence peut bien être considéré comme un DAL à part entière.
Le livre s’attarde ensuite sur la notion d’O/RM, avec la bonne idée de ne pas prolonger la polémique sur l’intégration forte ou faible de ces frameworks dans le métier. Il présente la notion de POCO ainsi que la Persistence Ignorance.
Le démontage des mythes sur les procédures stockées (page 333 et suivante) me paraît par contre un peu abusif. Je suis moi-même personnellement opposé à leur utilisation dans les DAL, mais je trouve que les auteurs y vont un peu fort, et sont même parfois de mauvaise foi. En s’attaquant au mythe de la sécurité supérieure des procédures stockées, ils vont un peu vite en besogne, en s’appuyant sur le fait que des requêtes ad-hoc peuvent être paramétrées également, pour ne pas s’exposer à l’injection SQL. C’est tout à fait vrai, mais le problème est que c’est beaucoup moins automatique. “On peut faire aussi bien avec de l’ad-hoc, donc les SP ne sont pas meilleures”, je trouve ça un peu limite. Une personne de mauvaise foi (bon, allez, je suis qualifié…) pourrait retourner l’argumentation et déduire logiquement qu’il faut un effort pour faire aussi sécurisé avec des requêtes ad-hoc qu’avec des SP. Et je crois qu’on est plus dans le vrai, là…
The Presentation layer
Je ne suis pas assez bon en couche de présentation pour me permettre de faire des réflexions sur le contenu de ce quatrième chapitre. Toutefois, je remarque juste l’absence du pattern MVVM, ce qui est dommage car je comptais sur ce livre pour mieux comprendre cette méthode d’architecture. Je m’y suis intéressé pour des raisons de testabilité, et vu le niveau du livre, je me disais que j’allais avoir une approche de haut niveau qui allait m’apprendre plein de choses, mais il a du sortir trop tôt pour que MVVM soit dedans. On retrouve donc le classique MVC, avec à nouveau quelques digressions complètement inutiles, comme par exemple “MVC : Pattern or Paradigm ?”. Franchement, je suis plutôt du genre à couper les cheveux en quatre, mais si je présente une architecture à mes coéquipiers et que quelqu’un me demande si c’est un pattern ou un paradigme, je serais personnellement affligé…
Je trouve un peu dommage que cette partie n’insiste pas plus sur la testabilité et sur la possibilité de mise en commun des architectures Windows et Web, mais il s’agit de préoccupations personnelles, donc c’est normal de ne pas toujours retrouver exactement ce qu’on veut dans un livre.
Lois de Murphy
Bon, pour en finir avec les reproches : chaque chapitre comporte à la fin une série de proverbes du type Lois de Murphy, et qui n’ont rien, mais absolument rien à voir avec le sujet du chapitre qui les contient. C’est marrant, bien sûr (normal, c’est de l’humour d’informaticien, et les auteurs savent à qui ils s’adressent), mais ça serait beaucoup mieux si ça avait un peu plus de rapport avec le sujet de chaque chapitre…
Conclusion
Vu que je suis un râleur (mes collègues confirmeront, bien qu’anonymement pour éviter un audit de code), je me rends compte que j’ai surtout parlé des quelques points faibles du livre, mais il ne faut surtout pas que ça vous donne une idée négative de celui-ci. Si j’ai fait un compte-rendu, c’est bien parce que c’est un des meilleurs livres d’architecture que j’ai lu. En tout cas la deuxième partie. Encore une fois, honnêtement, la première ne sert strictement à rien. Si vous lisez un livre d’archi, vous connaissez déjà ça. Ce n’est pas un reproche sur le contenu, mais juste pour que vous ne perdiez pas de temps si vous le lisez.
Mais cette deuxième partie est vraiment excellente. En à peine deux cents pages, vous avez couvert toutes les problématiques des architectures informatiques, avec une approche industrielle, pratique et pas du tout dogmatique, et la plupart des patterns standards de résolution de ces problématiques, complétés par leurs avantages et leurs inconvénients. Le fait de classer tout ceci par tiers est très appréciable, car si vous avez une question d’architecture, vous pouvez assez vite retomber sur les pages qui vous intéressent.
Bref, bravo à Dino Esposito et Andrea Saltarello pour cet excellent bouquin ! C’est rare d’apprendre autant de choses en aussi peu de pages…
PS : Executive Summary
Les auteurs ont eu l’excellente initiative de résumer les points absolument essentiels de leur livre en deux pages, tout à la fin. Je ne vais évidemment pas vous donner ces dix points ici, sinon vous n’achèterez pas le livre 🙂 Mais il y en a un qui m’a toujours paru fondamental, et je tiens à le rappeler ici : “Premature Optimization is the root of all software evil”. Pour avoir personnellement fait l’expérience de cette règle, je ne peux que souscrire à sa mise en avant par les auteurs. Après avoir perdu une bonne dizaines de jours de développement à écrire un système de transformation de données en mémoire, pour me rendre compte ensuite qu’avec des fichiers sur disque, c’était non seulement plus simple mais aussi plus rapide, je me suis demandé si je n’allais pas me faire tatouer cette phrase sur le front…
Bref, pour ceux qui ne le savent pas (mais je me demande si on peut réellement le comprendre sans en avoir fait soi-même la cruelle expérience…), il ne faut JAMAIS optimiser un système qui n’est pas encore complètement stable. Une fois les prérequis fixés, les demandes d’évolution satisfaites, avec un client qui comprend qu’une phase d’optimisation coûte cher et devra être recommencée de zéro sur une prochaine version, là, oui, vous pouvez vous lancer dans l’optimisation. Mais jamais avant.
Optimiser avant que l’application soit figée, c’est comme tirer sur un lapin au canon : même si, par chance, il tombe juste devant la ligne de mire, le temps que vous tiriez, il sera ailleurs. Et si, avec encore plus de chance, il ne bouge pas et que vous le touchez, il ne sera plus en état pour en faire quoi que ce soit après…
