Author Archives: Aurélien Pelletier

XML <=> javabean = Xstream

Voici le plus court chemin pour aller d’une structure XML à des javabeans et vice-versa: Xstream.

L’outil est impressionnant  de facilité et d’efficacité. Attention il s’agit d’un sérialisateur/désérialisateur => les structures objet et xml  doivent se correspondre. Il sait traiter les types simples tout comme les collections ou les maps. Une limite, il ne reconnait pas les attributs d’un élément mais seulement les sous éléments.

Dans le même genre il y a aussi jox

Si vous voulez faire du “mapping” xml < => objet, du xml databindings, il va falloir se tourner vers des solutions plus lourdes se basant sur un XML schema comme:
– Castor XML
– XMLBeans
– ou Jaxb

Ce ne sont pas les seules solutions, en voici une liste assez complète, selon un sondage sur manageability castor XML serait la solution la plus utilisée.

Inversion of control ou Dependency injection ?

L’année 2005 promet d’être celle des conteneurs légers basés sur l’Inversion of control et des notions de programmation orienté aspect.

Inversion of control comme le décrit Michael Spille ou Dependency injection terme inventé par Martin Fowler? La lecture de ces deux articles permet d’avoir les idées assez claires sur la question. Pourtant j’ai toujours eu le sentiment qu’il restait certains éléments m’échappant concernant ces concepts. Par exemple, quelle est la nature de la relation entre Ioc et depency injection si ce n’est pas la même chose?

Je viens de finir la lecture de “J2EE development without EJB” par Rod Johnson (à lire absolument pour tout architecte J2EE) et j’y ai, entre autre, trouvé la réponse à cette question.

L’Inversion of control est le principe selon lequel ce n’est pas à un objet lui-même de déterminer les dépendances dont il a besoin. Mais c’est à un élément externe et centralisé de déterminer pour l’objet les implémentations des autres objets qu’il va utiliser.
Cette technique permet d’assurer le découplage des objets ainsi qu’une grande souplesse dans les possibilités de paramétrage.

L’Ioc est un principe, il existe plusieurs manières de l’implémenter, on en distingue 2 :
– Dependency lookup
– Dependency injection

Le pattern dependency lookup consiste à utiliser un singleton couplé à une factory ou à un registry pour résoudre les dépendances entre objet. Si vous utilisez un service locator, une factory ou JNDI vous faites déjà de l’inversion of control. Mais cette approche présente un défaut : votre objet a au minimum une dépendance avec JNDI, un singleton ou votre factory.

Le pattern Dependency injecty permet de résoudre ce problème et de supprimer quelques lignes de code superflues. C’est le container qui va assembler les objets entre eux et résoudre les dépendances. Vos objets n’ont plus à “trouver” leurs dépendances, elles sont déjà là. Vos objets sont parfaitement découplés, ils ne dépendent plus d’aucune API.
Il existe un débat pour savoir si il vaut mieux utiliser des setters ou un constructeur pour faire l’injection de dépendance, il est quelque peu stéril, ça n’a pas grande importance. Utilisez la méthode qui vous convient le mieux. Si vous utilisez trop de setter ou si le constructeur d’un de vos objets a trop de paramètres c’est sans doute révélateur d’un problème de conception, un objet doit avoir un nombre limité de responsabilités, dans l’idéal une seule.

Voilà pour moi c’est enfin entièrement clair, et vous?

A use case for AOP

This week I had a nice training/presentation of a product call Docato, it’s an XML content management system based on a pure xml database: X-hive. The product is pretty good, it’s pure java and based on open standard.

One of the nice feature is the way you can extend it. With most software products you need to customize them to meet your customer requirements. Most products can be extended and customized by using hooks that are predefined by the vendor.

In the case of Docato they showed us how to extend it using AspectJ an aspect oriented framework. Using AOP means you can define your own hook to extend the product. This is very effective and powerfull. To work well it means that the product has a clean architecture and provide a good documentation of it’s internal API.

I think this a great use of AOP.