QI4J

Tiens tiens tiens …

Je suis tombé ce matin (enfin, plutôt la semaine dernière, mais je ne l'ai lu que ce matin) sur un framework Java qui me paraît mériter qu'on s'y intéresse, plus encore que j'ai pu m'intéresser jadis à Spring ou plus récement à Guice.
L'histoire de cette découverte est d'ailleurs marrante.
Il y a quelques temps, j'ai parlé à mes nouveaux collègues du mouvement NoSQL. Mouvement dont il faut retenir (à mon avis) deux choses
  1. Se définir uniquement par ce qu'on n'est pas, c'est invoquer le démon de la diversité (en même temps, Darwin nous dirait que c'est bon d'un point de vue évolutionnaire).
  2. Les bases de données relationnelles ont trente ans, il est temps de penser à autre chose …
A la suite de cette discussion, l'un de mes collègues m'a envoyé cette présentation de Neo4J, qui présente très bien les avantages d'une base de données orientée graphe. Dans cette présentation, il est dit que Neo4J peut être utilisé comme back-end QI4J. Comme je trouve Neo4J conceptuellement sympathique (à cause de sa proximité au web sémantique, RDF et toutes ces sortes de choses), j'ai été voir QI4J, et j'ai bien fait (et vous aussi, vous feriez bien).

Pour faire court, QI4J essaye d'appliquer les bonnes idées de l'injection de dépendances au seul domaine où ce soit complexe : le domaine métier. En disant ça, je caricature un peu, mais pas trop. Et je vais essayer de vous expliquer pourquoi; Avec Guice, Spring, PicoContainer et les autres, vous allez facilement pouvoir récupérer les services techniques de votre application : persistance, localisateur d'objets, service de recherche, envoi de mail, … Mais vos objets métier resteront instanciés par des POJOs. Et tout évolution de la modélisation du domaine métier se traduira par la réécriture de ces POJOs (et sans doute, par conséquent, par la réécriture du mapping objet/relationnel, de la couche IHM, …). Bref, ça va être le bordel. Et pour une raison somme toute simple : parce que vos objets métier fonctionnent indépendamment du contexte, alors précisément qu'un domaine métier est un contexte. Pour le dire dans des mots d'informaticiens, le domaine métier est souvent modélisé à l'aide d'instances d'objets, alors qu'il ne faudrait accéder qu'à des interfaces donnant les capacités des objets. Et là, je paraphrase encore le site de QI4J : dans un domaine métier traditionnel, je suis modélisé comme une personne, alors qu'au travail, je suis architecte, à la maison, je suis un père et un mari, et sur la route, je suis un démon à roulettes lors des Rol Friday Night.

Heureusement, QI4J est là !
Avec QI4J, vous modélisez votre domaine métier sous forme d'entités, d'attributs, et de relations. Et c'est QI4J qui va se charger de faire l'injection de dépendances de tout ce petit monde.
Pour donner un exemple, regardez le 10 minutes tutorial. Bien sûr, il n'est pas complet. Néanmoins, il permet bien de comprendre comment les choses s'articulent. Enfin, j'espère.

D'un autre coté, je commence tout juste à creuser avec vous. Néanmoins, je vois des choses très intéressantes, comme la modélisation des propriétés, qui me rappelle évidement magick-properties, ou encore les annotations beaucoup plus explicites que le @Inject ou même le @Named de Guice.

Bref, ça me paraît prometteur (surtout couplé à Neo4J pour fournir une persistance "sans effort") et je vais sans doute le tester de façon plus approfondie.

4 réflexions sur “QI4J

  1. Tiens, j’ai vu pass?? ??a sur une liste il n’y a pas si longtemps que ??a.Je ne suis pas conquis par ce genre de framework DDD. Peut-??tre ?? cause de leur maturit??. Quoi qu’il en soit je trouve que la d??finition du domaine s’en trouve d??ment complexifi?? (par la multiplication des interfaces notamment).Et puis ce n’est pas demain la veille qu’on verra ce genre d’approche sur des projets. Les techos pr??f??reront partir sur les nouveaux "langages" sur base de JVM type Scala.M??me si le passage de Java vers Scale m??rite un temps d’adoption certain, la d??marche du passage vers Qi4J n’en est pas moins longue.Et quid des performances dans ce genre de framework o?? les concepts de PO / DI / DDD nous cache la "moelle" de nos applications ?

  2. Ah ??a c’est s??r que c’est tr??s consomateur de performances ! <br/>Mais ?? mon avis, il y a quand m??me quelques id??es int??ressantes l??-dedans.

  3. Pingback: J’ai pas fait de crowdcast sur Javascript .. | riduidel's wordpress

Laisser un commentaire

Entrez vos coordonnées ci-dessous ou cliquez sur une icône pour vous connecter:

Logo WordPress.com

Vous commentez à l'aide de votre compte WordPress.com. Déconnexion / Changer )

Image Twitter

Vous commentez à l'aide de votre compte Twitter. Déconnexion / Changer )

Photo Facebook

Vous commentez à l'aide de votre compte Facebook. Déconnexion / Changer )

Photo Google+

Vous commentez à l'aide de votre compte Google+. Déconnexion / Changer )

Connexion à %s