Tester mon plugin de Génération de Code

Version imprimable

29/02/2012, 12h58
barzane

Tester mon plugin de Génération de Code

Bonjour à toute la communauté Eclipse de developpez.com.

Je vous propose de tester un plugin.

Il s'agit d'un générateur de code faisant du Mapping Relationnel Objet.
Autrement dit, il se connecte à une base de données, génère votre couche objet métier, puis la couche d'accès données.
Il ne vous reste donc plus qu'à faire appel aux différents Manager pour vos actions de CRUD (même si le "C" n'est peut être pas d'actualité).

Je vous remercie par avance pour vos retours.

Plugin https://docs.google.com/open?id=0B_k...TmlPNy1GZEx4Zw
Doc (plutôt pas du tout à jour): https://docs.google.com/document/d/1...be7402oaU/edit
02/03/2012, 01h43
azerr

1 pièce(s) jointe(s)
Bonjour barzane,

J'ai lu rapidement ta doc (même si elle n'est pas à jour) et je me permets de donner mon avis sur ton plug-in car j'ai pas mal bossé sur le sujet "génération de code" avec Eclipse où j'avais créé Akrogen un Plugin Eclipse de génération de code qui permet de déclarer tes wizard Eclipse en XUL et de les lier à un template (Freemarker, Velocity) pour générer du code.

Dans mon cas mon modèle sont les champs saisies dans le wizard, mais aussi une classe Java que l'on sélectionne avant d'ouvrir un wizard XUL, un fichier XML etc.... Dans ton cas ton modèle c'est la BD.

Je vais te donner mon point de vue sur la philosophie de ton plug-in mais je ne veux pas te blesser.

Aujourd'hui quand tu parles de génération de code dans l'écosystème d'Eclipse tu utilises EMF. Acceleo est un très bon exemple de générateur de code basé sur EMF. Et c'est dur de rivaliser à ça quand tu proposes un autre générateur de code.

Le problème d'EMF c'est la modélisation qui implique qu'elle se fasse par un diagramme UML, en utilisant un éditeur EMF, etc, alors que souvent on arrive dans un projet et il n'y a pas eu de modélisation de faite et, à nous développeurs, de se cogner le développement des couches Services/DAO, voire les formulaires de CRUD à coup de copier/coller d'une autre classe de Service/DAO simple. Que c'est ennuyeux de faire ça et surtout que de bugs avec ce copier/coller!

Mais pour moi dans un générateur de code ce qui est important c'est :
- pouvoir personnaliser les templates de génération de code pour générer le code que l'on souhaite (avec sa propre architecture).
- pouvoir générer du code, le modifier et relancer la génération sans que ça écrase le code qu'on aurait ajouté.
Je n'ai pas vu dans la doc ces 2 points? En ce qui concerne Akrogen il gère le premier point mais pas le 2ème.

EMF (JMerge du moins avec Java) gère le 2ème point (avec les annotations @Generated) et c'est l'une des grande force de EMF. Acceleo lui apporte une "ferme" de templates considérables qui permet de générer du Spring, de l'Hibernate etc...Et tu peux même débugger tes templates!

Je vais me répéter encore mais le problème avec EMF c'est de devoir modéliser l'application en UML dès le départ et généralement quand on arrive sur un projet c'est pas du tout comme ça. Pour moi l'idéal d'un générateur de code c'est de pouvoir partir d'un modèle X (classe Java, BD, XML, etc...) et pouvoir utiliser les templates qui attendent un modèle EMF avec Acceleo par exemple pour bénéficier de l'outillage sur les templates.

Prenons un exemple de ce que j'aimerais faire (sans parler de EMF):
- tu sélectionnes une table -> tu génères la classe model/domain
- tu sélectionnes la classe model/domain -> tu génères ta couche DAO.
Comme tu peux voir tu as un modèle BD et un modèle Java. Ce qui serait génial c'est de pouvoir faire en transparence
- Sélection table -> modèle EMF -> Template Acceleo -> Génération classe model/domain
- Sélection class model/domain -> modèle EMF -> Template Acceleo -> Génération classe DAO
Le 2ème point j'avais réussi à le faire en utilisant Modisco (qui permet de transformer une classe Java en modèle EMF). J'avais commence le projet JM2T (Java Model 2 Text) mais je n'ai pas eu le temps de le continuer (je t'ai attaché un odt pour te donner une idée du plug-in).

Pour terminer, concernant la couche DAO, si tu as la chance d'avoir Spring + JPA, je conseille Spring Data JPA qui m'a bluffé. Il n'y même plus besoin de coder son code JPA et sa DAO! Tout marche avec convention de nommage de la méthode de l'interface de la DAO (ex : il suffit juste de déclarer dans l'interface DAO l'intreface findPersonByName(String name) et c'est tout!) Spring Data sait qu'il doit travailler sur l'entité Person et faire du JPA dessus. Dans ce contexte ci la génération de code n'a plus raison d'être.

Bonne chance pour ton plug-in.

Angelo
02/03/2012, 18h58
barzane

Salut!

Bonjour azerr,

Merci déjà de l'intérêt que tu as accordé a mon post.
Je dois déjà te présenter l'état d'esprit dans lequel j'ai décidé de me lancer dans mon plug-in. C'est pour des raisons totalement empiriques. Voila je me retrouve tout seul dans un projet (personnel) avec plus de 200 tables. Je n'ai aucune expérience en Hibernate et je me lance dans la doc. Tout de suite je vois du xml, du blablasql (désolé pour les passionnés) qui me révulsent. Je comprend pas pourquoi dans mon projet java je devrais me farcir tout ça.

Alors je me souviens que je peux créer mon propre plug-in, qui, suivant le modèle de ma BD, pourra me générer mes classes objets et donc ma couche Objets Métier. A coté de ça je vois bien que les opérations de CRUD sont répétitives dans mon code; alors je me décide d'ajouter à mon plug-in une couche Accès Données qui fait office de DAO.

Ceci dit, tout ça dans quelle philosophie?
Déjà affirmer qu'" Aujourd'hui quand tu parles de génération de code dans l'écosystème d'Eclipse tu utilises EMF" ne peut pas être vrai puisque je fais de la génération sans EMF.

Aussi je ne modélise pas UML que je trouve trop élastique. La rigueur merisienne pour moi est une qualité. Et donc si pour une application qui repose sur un modèle relationnel (car la réalité d'une application de gestion ce sont les données qu'elle manipule) pourquoi y greffer du UML?
Le plug-in se nomme Ongola ROM. ROM pour Relational Object Mapping. Et donc le seul template valide pour moi c'est le MLD que je gère!!!
Ce template est sacré!! Lol! Aussi la modification n'a de sens que si on schéma de la BD change. L'utilisateur peut gérer la couche métier à ça guise mais pas les objets métiers ni la couche DAO (perso) que je génère et qui épouse les contraintes de la BD.

Tout ce que l'utilisateur a à faire c'est mettre les objets métiers dans des containers (listes,tableaux...) et les enregistrer, afficher, modifier, supprimer.
Donc mon plug-in n'effectue pas que de la génération de code; c'est aussi de l'automatisation du développement en automatisant les les étapes incontournables et répétitives. On y retrouve aussi la validation et le logging.
En terme de validation seul les contraintes CHECK ne sont prises en compte. Le logging lui va servir au débogage.

Et ça c'est qu'un début. Pour le moment il n'est pas possible de modifier le schéma de la BD via le plug-in et mettre ajour automatiquement le code. J'y réfléchis. Aussi on peut envisager la génération de formulaires...

Bref je suis loin de penser que mon plug-in est parfait. Mais je le crois pertinent et surtout il a une philosophie totalement empirique.
Aussi je serai bien content que tu me dises que tu l'as quand même essayé :lol:.
Merci de l'intérêt et il me tarde de lire tes prochains avis.
05/03/2012, 00h23
azerr

Bonjour barzane,

Citation:

Alors je me souviens que je peux créer mon propre plug-in, qui suivant le modèle de ma BD, pourra me générer mes classes objets et donc ma couche Objets Métier. A coté de ça je vois bien que les opérations de CRUD sont répétitives dans mon code; alors je me décide d'ajouter à mon plug-in une couche Accès Données qui fait office de DAO.

J'ai eu le même sentiment que toi quand j'ai décidé de créer Akrogen. Mais ce qu'il faut bien se mettre en tête c'est que le plug-in ne doit pas générer une architecture en particulièr mais doit permettre d'ajouter son propre module de template pour générer une autre architecture. Si tu ne fais pas ça ton plugin ne sera jamais utilisé car quand tu arrives dans un projet tu as déjà une architecture mise en place.

Par exemple dans mon cas nous avons un projet Eclipse RCP/RAP basé sur JPA + Spring Data JPA (voir démo Eclipse RAP) et je souhaiterais générer cette architecture (et pas celle imposé par un plug-in de génération de code).

Citation:

Déjà affirmer qu'" Aujourd'hui quand tu parles de génération de code dans l'écosystème d'Eclipse tu utilises EMF" ne peut pas être vrai puisque je fais de la génération sans EMF.

Moi aussi avec Akrogen je fais de la génération de code sans EMF (avec Freemarker et Velocity), mais tous les plug-ins pros de génération de code sont principalement basé sur EMF qui te donne un tas de possibilité (comme la possibilité de régénérer le code sans écraser le code qu'on aurait ajouté à la main). Faire concurrence a un plug-in comme Acceleo ça me parait très difficile (c'est pour ça que j'avais commencer à créer JM2T).

Citation:

Aussi je ne modélise pas UML que je trouve trop élastique. La rigueur merisienne pour moi est une qualité. Et donc si pour une application qui repose sur un modèle relationnel (car la réalité d'une application de gestion ce sont les données qu'elle manipule) pourquoi y greffer du UML?

Je ne vais pas rentrer dans ce débat. Moi même je ne suis pas fan d'UML. Partir du modèle de donnée SQL je pense qu'aujourd'hui ça devient moins d'actualité. Surtout que tu peux générer ton schéma SQL via JPA et ses annotations (c'est ce qu'on fait nous dans notre projet). Tu modélise tes POJOs avec tes annotation et tu génères ton schéma de BD sans une ligne SQL et tu peux switcher d'une BD à une autre. Aujourd'hui c'est plus ça la philosophie je pense. Pas l'inverse.

Citation:

Donc mon plug-in n'effectue pas que de la génération de code; c'est aussi de l'automatisation du développement en automatisant les les étapes incontournables et répétitives. On y retrouve aussi la validation et le logging.

Si je comprends bien tu fournis un framework qui génère le code de tes services DAO etc... Si dans mon projet où j'utilise Spring Data je voudrais utiliser ton plug-in, est-ce possible?

Citation:

Donc mon plug-in n'effectue pas que de la génération de code; c'est aussi de l'automatisation du développement en automatisant les les étapes incontournables et répétitives. On y retrouve aussi la validation et le logging.

Je me répètes mais j'ai l'impression que ton plug-in génère qu'un type de framework. Si tu imposes un framework, je ne suis sur que le plug-in marchera bien (ça n'est que mon avis).

Citation:

Aussi je serai bien content que tu me dise que tu l'as quand même essayé

Je n'ai malheureusement pas beaucoup de temps à y consacrer car j'ai déjà une pile de chose a explorer :-(

Je voulais juste te souhaiter bonne chance car je sais que c'est difficile de faire connaître son projet et surtout ça prends du temps (j'ai fait plusieurs projets open sources et ce n'est qu'au bout de 1 à 2 ans que les projets commencent a se faire connaître), il faut arriver à garder la motivation.

Tu devrais vraiment essayer Spring Data JPA. Tu as juste à créer une interface Service et c'est tout!! (Spring Data te gère ta DAO avec du CRUD+Pagination). Depuis que j'utilise Spring Data ma vie a changé.

Bonne chance!

Angelo