Mardi 6 juillet, 19h30, 211 Geeks, 2h de conférence, 30mn de buffet, une présentation sur Java EE 6, un speaker très bon, voilà comment résumer rapidement la soirée d’hier soir. La vidéo de la session sera sur Parleys.com cet été, je vous tiendrai au courant.
Adam Bien est consultant indépendant, Java Champion, auteur de plusieurs livres en anglais et en allemand sur Java. Il a carte blanche ce soir pour présenter Java EE 6 par la pratique. La présentation s’est découpée en 2 parties. Pendant la première heure, nous avons plus parlé conception et architecture. La deuxième heure fut une démonstration de programmation en direct. Les quelques 200 geeks présents ont bien apprécie et le message est passé.
Java EE 6 est plus simple, plus rapide, plus facile à apprendre et plus productif que Java EE 5. Si votre entreprise utilise encore Java J2EE 1.4, il est temps de regarder la dernière version. Dites bye-bye aux nombreux fichiers de configuration XML, le framework est vraiment bien pensé.
Avant que quelqu’un ne pose la question, il parle de Spring vs JEE 6. Spring offre plus de configurations, le framework est vraiment très configurable. Java EE 6 utilise plutôt des conventions afin de ne pas avoir à tout déclarer. Le conteneur EJB est vraiment petit. Moins d’1Mb. Il nous montrera par la suite que Glassfish v3 est vraiment véloce, dès lors qu’il s’agit de déployer une application.
Nous attaquons enfin le cœur du sujet, discussion qui va faire mal aux yeux pour certains architectes, pour mon plus grand plaisir. Adam Bien parle tout d’abord du pattern d’architecture « Boundary/Control/Entity » et de son application dans l’architecture des futures applications JEE 6. C’est un pattern similaire au pattern MVC, avec cependant une approche plus adaptée aux applications webs.
Il encourage une nouvelle approche basée sur la philosophie D.D.D (Domain Driven Design), où l’Entité n’est plus agnostique, où les Data Access Objects ne sont pas utiles. En clair : plus de DAO. Comme il va l’expliquer ensuite, vous avez beau mettre des couches et des couches, cela ne bloque pas pour autant l’évolution.
L’approche DDD (voir le compte-rendu de la formation de Zenika) met au premier plan le Domaine. Les Entités deviennent plus importantes que les Services. L’approche de ces dernières années, avec service/domain/dao est ce que l’on appelle l’approche orientée service. C’est une approche pratique pour les clients légers, pas forcément pour les applications webs. L’approche DDD fait que vos Entités portent des méthodes métiers. Le DAO de votre système est l’Entity Manager, qui se retrouve injecté dans votre Entity ou sinon simplement dans votre service.
Ce principe fait que les services, et les contrôleurs dans le Web, perdent la logique de l’application. L’architecture avec état permet alors d’adresser d’autres problèmes plus simplement qu’avec l’approche classique orientée service.
J’aime beaucoup ce concept. C’est l’approche de Play! Framework et je constate avec plaisir que c’est donc un mouvement qui peut aussi s’appliquer rapidement avec Java EE 6.
Les architectures classiques appelées « Service Driven Architecture » sont ce que nous faisons tous plus ou moins. Une couche de domaine, une couche DAO, une couche Service. Les Entities du domaine sont anémiques et ne sont que le reflet de la base de données. Les DAO ne servent souvent pas à grand chose. Les NamedQueries qu’ils portent pourraient être placées sur les Entités comme dans l’approche DDD. C’est une manière de programmer assez procédurale. Les Services sont les responsables de la logique de l’application. Cela marche bien si vous devez faire des Web Services et du SOAP, ou des architectures sans état. Mais cela vous demandera plus de code.
Adam parle ensuite des Interfaces et commence à nous montrer notre premier Bean Java EE 6 :
@Stateless
public class SimpleSample {
public void doSomething() {
}
}
Voilà c’est tout. Pas de XML de configuration et pas d’interface. Adam décourage l’usage des Interfaces si vous n’avez pas de réelles motivations architecturales. Les gens continuent à penser qu’il faut des interfaces pour que le code soit testable. C’est faux et cela fait 5 ans que l’on vous le dit. Allez lire cet article sur Mockito pour comprendre. Il est tout à fait possible de mocker des classes, c’est très simple. Donc définir une interface pour les tests : pas une bonne pratique. Par contre définir une interface pour structurer son application : oui si cela vous permet d’utiliser des choses comme le Strategic Pattern par exemple. Même pour les interceptors et les dynamiques proxies : Java EE 6 est capable de se baser sur les annotations et de gérer vos Beans très simplement.
Nous passons en revue les différents Beans de Java EE 6, les Entities, les Interceptors et même les Cron. Tout est relativement simple, et permettra d’écrire des applications rapides et puissantes. Investir en 2010 dans un livre sur Java EE 6 me semble une bonne idée pour les architectes et les développeurs. Vivement que nous puissions en faire dans nos projets. Cela fera des économies et redonnera du plaisir à utiliser Java EE en général.
En résumé pour cette première partie, Adam nous a montré qu’il est intéressant d’apprendre une nouvelle manière de construire une application d’entreprise, en se basant sur l’approche DDD plutôt que l’approche SOA. J’ai vraiment bien aimé cette partie, c’est une approche qui renforce la simplicité. Je pense qu’il va y avoir de longs articles pour montrer cette nouvelle approche. C’est très religieux, et proposer une nouvelle approche ne se fera pas sans grands débats enflammés, jusqu’à ce que tout le monde se rende compte qu’il avait raison.
A la pause, nous avons discuté autour du buffet. La remise en question de la tartine « domain/dao/service » ne va pas forcément convenir à tout le monde. Comme le dit Adam, ce n’est pas une mauvaise pratique. C’est une pratique qui n’est pas adaptée à tous les problèmes. Lorsque votre domaine est assez riche, il est plus facile de prendre l’approche DDD. Ce n’est pas plus compliqué, cela demande une petite remise en question de nos connaissances. Mais après tout, on apprend en permanence non ?
Après le buffet, nous avons eu une bonne heure de démonstration de Java EE 6. Avec des exemples de code, il a démontré qu’il était pratique et simple de travailler en 2010 avec Java EE 6 et Glassfish. Pour cela, il conseille d’utiliser NetBeans 6.9.
Pour terminer, je pense qu’il faut que je bosse sur un article afin de vous montrer les similarités d’approche entre Java EE 6 et Play! Framework. Si à terme un standard comme Java EE 6 me permet de coder de la même manière qu’avec Play! alors je serai le plus heureux des développeurs. Et même si j’adore Play!, je serai encore plus heureux d’utiliser un standard pour ma partie serveur, avec cette nouvelle approche plus simple.
Adam Bien sera ce vendredi dans le sud à la conférence SophiaConf 2010 organisée par l’équipe du Riviera JUG de Sophia-Antipolis. Ne manquez pas sa présentation !
Rendez-vous à la rentrée pour le Paris Java User Group, passez de bonnes vacances. Merci à José Paumard pour les excellentes photos.
Merci pour ce feedback, j’ai passé bonne soirée également. Adam a des idées bien arrêtés sur un certain nombre de sujet !
Ça fait plaisir de voir enfin plus de monde qui parlent bien, le DDD, les interfaces qui polluent le code, les objets anémiques, … Ça fait un bout de temps que j’ai de plus en plus de mal à accepter ces anciennes pratique par dogme.
Pour le coup j’ai encore des doutes sur l’injection de dépendance
Je me souviens que lorsque tu parlais de DDD tu parlais du développement objet, mais comme Adam Bien je pense que aujourd’hui on ne fait pas vraiment d’objet, on utilise juste des structure publiques, on fait du script avec des namespaces. En bref on ne fait pas d’objet. Et aujourd’hui dans une entreprise, c’est plus que dur de faire changer les esprits à dessus. Voire pire, les décisions sont prises et imposées par un petit commité qui va choisir dans des valeurs sure (comprendre leurs vieux repères) et standardiser, ce qui a pour conséquence de ne pas pousser les développeurs à apprendre, à réfléchir.
Évidement je ne dis pas qu’il faut tout laisser faire, j’ai typiquement vu des projets, ou les gens ont ajouter tous leur jouets dans une même application sans réelle vision. Justement le juste milieu serait d’avoir une vision d’architecture, des guides de pratiques, et surtout une conduite du changement (parce qu’évidement on ne va pas réécrire d’un coup 500000 lignes de code ou même seulement 20%).
Il faudrait toujours avant de coder au moins se poser les questions pourquoi je fais ça, est-ce que j’en ai besoin, est-ce que je l’utilise bien. Bref se challenger soi-même et tout le temps. Encore faut-il avoir du recul, mais quand on fait du pair programming, ces questions viennent généralement naturellement, du coup je dis que c’est bien le pair programming.
A ce sujet je pense que DDD avec BDD/TDD aidera vraiment à concevoir des applications bien pensées, encore faut-il avoir les bons réflexes. D’ailleurs si une entreprise veut diminuer ses coûts, elles n’a pas d’autres choix que de pousser les compétences de ses développeurs plutôt que de les brider (et bien évidement de les reconnaitre sous la forme de rémunération, je comprends les gens qui deviennent chef de projet pour avoir un meilleur salaire si ça leur permet d’acquérir une maison!).
Pour finir je souhaite refaire l’apologie d’un livre plutôt bien qui s’appelle Growing Object Oriented Software Guided by Test.
Également aussi je rappelle le site du mouvement anti if http://www.antiifcampaign.com/
Hello,
Merci pour ce retour,
A cause d’un contre temps perso, je n’ai pas pu venir hier soir..
Je cours sur Parleys faire ma séance de rattrage.. 🙂
Super intéressant!
« Si à terme un standard comme Java EE 6 me permet de coder de la même manière qu’avec Play! alors je serai le plus heureux des développeurs »
C’est exactement ce que je me dis depuis un moment!
« Le DAO de votre système est l’Entity Manager, qui se retrouve injecté dans votre Entity ou sinon simplement dans votre service. »
Mort aux DAO, je suis bien d’accord, en plus l’entitymanager est ultra générique, il permet de taper sur toute sortes de supports de persistence (voir l’implem JPA de BigTable pour le NoSQL). Je me demandais si il était possible d’injecter un em dans les entités avec CDI, apparement oui c’est une bonne nouvelle!
Excellent article, merci Nicolas.
J\’aime cete approche qui est simple. Je suis egalement un grand fan de play. Je me demande comment reussir a vendre cette archi dans les cellules transverses et aux architectes qui semblent bien accrochés à leur satanés dao.
Même si je suis entièrement d’accord avec Adam Bien, une raccourci comme celui de Nicolas:
« Si à terme un standard comme Java EE 6 me permet de coder de la même manière qu’avec Play! alors je serai le plus heureux des développeurs. »
est dérangeant.
Désolé, mais ça n’a rien de nouveau, qui et/ou quoi dans JEE vous laisse penser que l’adoption d’une couche DAO est conseillée? Ce n’est qu’un choix d’architecture.
Idem pour ce qui est des entités agnostiques, aka DTO débiles.
En gros depuis 2002 (merci les ORMs mûrs et hibernate) et la possibilité de concevoir une appli selon DDD car persistance de POJO modélisés sans limitation, on aurait du assister à la disparition générale des DTOs.
Depuis JPA 1.0 (donc << pas Java EE6), l'entity manager est effectivement un DAO possible.
Enfin je ne comprends pas
"Le DAO de votre système est l’Entity Manager, qui se retrouve injecté dans votre Entity ou sinon simplement dans votre service. "
Qui exploite l'entity manager dans les entités (classe annotée avec @Entity, c'est bien ça?)? Qqun peut me donner un exemple ? Voire l'intérêt ? A moins que je ne passe à côté de la susceptibilité, c'est un anti pattern!
après qques recherches, je suis tombé sur les arguments de Adam
http://www.adam-bien.com/roller/abien/entry/why_sometimes_the_entitymanager_in
Il a son avis, très respectable, mais il y a qqch d’antinomique dans les arguments.
Peut-on:
– d’un côté mettre en avant l’approche DDD via JPA et la persistance de POJOs métier enrichis en comportements métier
– d’un autre côté enrichir ce Domain Model __techniquement__ en y ajoutant des lignes d’accès aux données via l’entity manager ? Ce qui l’empêche d’être un POJO puisqu’il est désormais ultra dépendant de JPA, il ne peut plus être simplement sérialisé.
Très bon résumé de la soirée. La présentation m’a vraiment donné envie de tester JavaEE 6 quand j’aurai un moment de libre.
La démonstration était très convaincante (et prouve une fois de plus que Netbeans, ça roxx :D), je conseille à ceux qui l’ont ratée de regarder les vidéos qui ont été prises au cours de la soirée lorsqu’elles seront publiées.
Agreed? 😉
@Patricio
Il faudrait un autre livre appelé Real World Anti-Patterns.
@Patricio si on veut supprimer les couches services, et tout recentrer sur le modèle, on est amené à effectuer les accès à la base depuis les entités.
Par exemple un objet est capable de s’auto-sauvegarder ou d’accéder à ses objets liés en appelant la base si il a accès à l’entity manager
Enfin c’est une façon de faire, avec play par exemple on peut appeler la base depuis les entités ou depuis le controlleur (via des méthodes statiques qui se trouvent… sur les entités)
@Brice
je ne comprends pas le sens de ta remarque mais j’ai ajouté des arguments sur un commentaire suivant ‘en attente de modération’, je suppose qu’il n’est pas encore visible
@Loic
« si on veut supprimer les couches services, et tout recentrer sur le modèle »
Attention aux responsabilités des composants aussi. Moi perso, je suis 200% pour la flexibilité afin de coller au mieux aux besoins de l’appli plutôt que de suivre un quelconque dogme de séparation en couches.
Cependant, pour moi, il est primordial de définir les rôles des composants. Ajouter de l’accès aux données, donc de la technique à un business POJO persistant (définition possible d’une entité non anémique ?) c’est lui ôter son aspect POJO et lui adjoindre différents types de responsabilités dans des domaines différents.
A propose des Pojo, les EJB 3.x sont qualifiés de Pojo et pourtant ils ont bien une responsabilité liée à la persistance…
Apres tout dépend du type d’architecture que l’on recherche, dans play, utiliser la méthode save() sur une entité (qui hérite de la classe Model de play) ne me parait pas choquant, c’est cohérent avec l’architecture du framework…
D’un autre côté on peut préférer utiliser un service externe pour accéder à la base même en ayant un domaine non anémique, comme en DDD avec le concept de repository (bon ça ressemble un peu à du DAO du coup…)
@Patricio
C’était en relation avec le livre de Adam Bien, Real World JEE Patterns et ton commentaire sur les DTOs. Un livre sur les anti-pattern, les choses à ne vraiment pas faire, serait un bon complément des patterns.
@Patricio Les commentaires sont en fait mis en modération lorsqu’ils contiennent des URLs. Je dois alors manuellement les approuver. Et ce, pour éviter le spam
Quand j’ai commencé à développer, sur l’application sur laquelle je travaillait, on refactorait des objets qui contenaient toute la logique métier+accès base, on extrayait la logique métier et les accès bases pour avoir un modèle service/dao qui manipulait ces objets devenus de simples pojos.
Est-ce que le fait de faire des « pojos métier enrichis en comportements métier » ne serait pas un retour en arrière?
Je ne sais pas si mettre de la technique dans une entité métier est un retour en arrière mais cela fait penser au concept des « Entity Bean » (qui est Pruné dans Java EE 6) où une entité métier s’autopersiste (s’automerge, etc.).
Ce concept à l’époque devait révolutionner le principe de persistance mais a échoué car trop complexe (à cause des EJB 2.x dont la spéc était sous spécifiée sans compter le manque de portabilité d’un serveur d’applications à un autre à cause des descripteurs de déploiement spécifiques à chaque serveur surtout pour les Beans CMP dont la persistance est gérée par le conteneur).
Pourtant, ce concept n’est pas déconnant dans une logique DDD. Après tout, il y a bien des technos qui ont échoué il y a 10 ans et qui en ressortant aujourd’hui montent en popularité…
Super ton article Nicolas, merci beaucoup! Je voudrais juste te faire une petite remarque, j’ai peut-être mal compris ton CR corrige moi si c’est le cas.
Tu dis en gros que c’est l’approche de l’architecture DDD qui fait disparaitre (ou plutôt adapter je dirai) l’utilisation du pattern DAO.
Par contre, à mon avis Adam a mise en cause le pattern DAO dans le cadre JEE5 et JEE6, indépendamment d’approche qu’on utilise : SOA ou DDD.
De la même manière, il encourage l’utilisation du DDD, oui, mais il dit aussi que les deux approches sont nécessaires, et que en général toute entreprise dans ses projets aura besoin des architectures mixtes. En gros, il encourage à bien identifier les vrais besoins (par rapport les interfaces, les DAO et autres patterns) et de se lancer avec DDD qui est bien plus pratique (il ensemble avec REST, et SOA avec SOAP) mais il ne dit en aucun cas d’arrêter le SOA.
Il a publié trois articles en Java World qui expliquent tout cela aussi. Si tu les connais pas, tu peux les trouver à partir de notre premier article sur Adam Bien chez JDuchess.
Fais-moi les remarques que tu voudrais, je suis en train d’écrire le 2ème article sur ce sujet et je veux m’assurer de que mon information est pertinent.
Merci beaucoup encore pour ton CR!
J’espère m’avoir bien expliqué!
Je reformule un paragraphe pour qui soit plus clair :
A mon avis il nous encourage à bien identifier les vrais besoins (par rapport les interfaces, les DAO et autres patterns) et de se lancer avec DDD qui est plus pratique dans certains cas (il ensemble avec REST, et SOA avec SOAP) mais il ne dit en aucun cas d’arrêter le SOA.
Bonjour Katia,
Oui en effet, Adam était plus « mesuré » que moi. Je suis allé lire vos articles sur JDuchess.fr et j’ai trouvé cela très intéressant. Bravo pour le travail et pour le retour.
Nicolas
« Les gens continuent à penser qu’il faut des interfaces pour que le code soit testable. […] Donc définir une interface pour les tests : pas une bonne pratique. Par contre définir une interface pour structurer son application : oui »
C’est marrant ça. Avec le temps, j’en suis venu à considérer que mocker autre chose que des interfaces était soit un test smell, soit un design smell.
Attention : je ne dis pas qu’il faut systématiquement définir une interface pour mocker un truc. C’est plutôt l’inverse : si je me retrouve à vouloir mocker un truc qui n’est pas une interface alors je me dis que :
– soit mon test n’est pas effectué au bon niveau (il est trop proche de l’implémentation pour être utile et pérenne)
– soit mon code n’est pas correctement architecturé (il manquerait une interface et pas que pour du test)
Bonjour,
CR de la partie théorie et de la partie pratique chez les JDuchess.
http://jduchess.org/duchess-france/
Cordialement,
Katia