Discussion :

[Aéris22]

Hello les gens !

J'aurais aimé avoir un retour d'expérience et/ou une estimation de vos vitesses de développement de mapping Hibernate.
J'ai un nouveau projet dans les tuyaux, et j'aimerais arriver à une estimation assez précise d'un point que je n'arrive pas du tout à anticiper.

En gros, j'ai un XSD qui m'est fourni. Via XJC, je suis en mesure de générer tous les .java nécessaires à cette application.
Ensuite, je modifie à la main les classes générées par XJC pour décrire mon mapping hibernate et permettre la persistance de mes données dans une base relationnelle.
Ordre de grandeur : 300 classes, 2500 getter, 1200 relations simples, 250 relations multiples.

Donc questions à 10 balles :
— Quelle estimation vous mettriez sur un travail aussi important de mapping*?
— Et si on ajoute le portage des contraintes XSD (range, cardinalité, valeur…) via du Hibernate Validator*?
— Est-ce qu'il existe un outil capable d'automatiser tout ça (XSD*→*mapping Hibernate)*?

Merci d'avance

[tchize_]

Ordre de grandeur : 300 classes, 2500 getter, 1200 relations simples, 250 relations multiples.

Un monstre quoi

Donc questions à 10 balles :
— Quelle estimation vous mettriez sur un travail aussi important de mapping*?

C'est toujours difficile d'estimer un truc comme ça sans en connaître le contexte.

Comme souvent, quand on n'arrive pas a estimer un volume de travail, on le divise et fait temps estimé d'un item * nombre d'items . On peux par exemple regarder chaque élément séparément:

annoter un getter simple: 1 minute, le temps de tapper les 2 ou 3 @ pour définir son type et sa colonne. On peux skipper si on veux le comportement par défaut de hibernate => 2500 minutes ~ 6 jours

relation simple: compte plutot 2 minute, le temps d'aller voir l'autre coté de la relation, de déterminer qui gère la relation, de déterminer les règles de lazy loading. => 2400 minutes ~6jours

Relation multiple: on parle de many to many ou de relation à 3 voir 4 éléments? Premier cas comme les simple. deuxième cas, compte plutot 30 minutes pour dépétrer chaque spaghetti . Allez j'opte pour le premier 1.5 d'une journée de travail

Services (pour trouver les classes, gérer la session, charger, sauver) => à la demande: tu ne va pas écrire un service pour les 300 classes, tu ne vas, je doute que tu prévoie 1000 points d'entrée dans ta librairie.


Tester les classe ("écrire un test qui charge hibernate, remplis une classe, la sauve, la récupère, compare, afin de tester les mapping): en général le même temps que pour écrire le mapping. Faut autant de temps pour décider ton mapping que pour faire une appel à set, un load et un assertEquals

a pifomètre, j'arrive à 1.5 mois, à réévaluer après une semaine de travail pour avoir les mesures réelles. En supposant quelqu'un qui connaisse bien hibernate. Tu peux facilement doubler ou tripler si le type va s'emmeler dans un framework qu'il ne connait pas.

— Et si on ajoute le portage des contraintes XSD (range, cardinalité, valeur…) via du Hibernate Validator*?

Combien de temps pour une contrainte * nombre de contraires + tests

— Est-ce qu'il existe un outil capable d'automatiser tout ça (XSD*→*mapping Hibernate)*?

Ben si un outil peux te générer les classes, on peux surement l'adapter pour générer les contraintes au passage Pour ce qui est du mapping, faut savoir que, a priori, un @Entity sur la classe devrait suffire (de mémoire, même les relations sont gérées automatiquement). Donc si tu veux un comportement automatique, tu peux te contenter d'écrire 300 fois @Entity et raccourcir ton temps de dev, mais c'est pas garantis sur un paquet de 300 classes auto générée que t'aura pas des merdes à ramasser à la pelle

[Aéris22]

Un monstre quoi

C'est un peu l'impression que j'en ai, avec en plus des contraintes supplémentaires (cf plus bas) et du coup, je risque de vite foutre un gros coeff de sécu sans m'en rendre compte.
D'où la demande d'un avis extérieur =)

C'est toujours difficile d'estimer un truc comme ça sans en connaître le contexte.

Ça je te l'accorde.

En gros, j'ai un XSD qui est imposé par l'utilisateur final. XSD orienté à 1.000% métier, donc je n'ai absolument aucune chance d'arriver à comprendre quoi que ce soit des données manipulées sauf à avoir 20 ans devant moi.
Au final, je cherche juste à respecter la structure hiérarchique pour ma persistance et appliquer ensuite «*bêtement*» les recettes de cuisine que me donnera mon utilisateur final pour le reste de la partie système d'info (import, export, règles de gestion…).
Un beau challenge en perspective de coder une appli sans savoir ce qu'on manipule

annoter un getter simple: 1 minute

Sur un cas standard, j'aurais été d'accord avec toi.
Mais là, sans compréhension des données manipulées, je vais devoir aller voir à la mimine dans le XSD si le champ est obligatoire ou pas par exemple. Le XSD fait 23.000 lignes
Et du coup, je pense plutôt être à 5min qu'à 1, non ?

relation simple: compte plutot 2 minute

OK sur du standard, mais là idem, j'ai aucune connaissance de ce que je vais avoir de l'autre côté de la relation. @OneToMany ou @OneToOne ?
Pas d'autre choix que de mettre la main dans le XSD ou dans la classe duale.
Et du coup, 2min, ça me paraît… court

Relation multiple: on parle de many to many ou de relation à 3 voir 4 éléments?

Non, on reste dans des relations duales. Pas de ternaire ou autre, ouf…
Mais idem point précédent, @ManyToOne ou @ManyToMany ?

Services: tu ne va pas écrire un service pour les 300 classes

On est d'accord, tous les services de persistance sont mutualisables de toute façon et les services spécifiques sont… spécifiques
Cette charge est en dehors du scope de l'estimation et est moins floue à estimer pour moi.

Faut autant de temps pour décider ton mapping que pour faire une appel à set, un load et un assertEquals

Ça c'est la partie qui est la plus floue pour moi.
Faire un test simple qui va save, fetch, assert, oui, c'est rapide.
Quand tu commences à vouloir tester un objet qui va avoir 10 propriétés dont 8 not nullable et 3 en associations multiples, la galère des dataset pour avoir un objet qui va passer le save sans se bouffer des «*null on not nullable entity*» et autre joyeuseté*

1.5mois

Je prend note.
Dans le cadre d'un projet «*standard*» où c'est toi qui a la main sur ton modèle de données et où tu le comprends, c'est aussi ce que j'aurais dis.
Mais là vu la contrainte de non compréhension du modèle, ça me semble assez faible et en tout cas 'achement risqué comme prédiction =)

facilement doubler ou tripler si le type va s'emmeler dans un framework qu'il ne connait pas.

mais c'est pas garantis sur un paquet de 300 classes auto générée que t'aura pas des merdes à ramasser à la pelle

Ah bon, tu crois vraiment ???

[sinok]

http://www.eclipse.org/eclipselink/moxy.php

[tchize_]

Sur un cas standard, j'aurais été d'accord avec toi.
Mais là, sans compréhension des données manipulées, je vais devoir aller voir à la mimine dans le XSD si le champ est obligatoire ou pas par exemple.

T'as mis les contraintes à part, je les ai évaluées à part

OK sur du standard, mais là idem, j'ai aucune connaissance de ce que je vais avoir de l'autre côté de la relation. @OneToMany ou @OneToOne ?

Ben X getX() -> onetoone ou manytoone (regarder l'autre coté de l'implémentation)
Set<X> getX() -> ont to many ou manytomany (encore une fois, regarder de l'autre coté )

Ça c'est la partie qui est la plus floue pour moi.
Faire un test simple qui va save, fetch, assert, oui, c'est rapide.
Quand tu commences à vouloir tester un objet qui va avoir 10 propriétés dont 8 not nullable et 3 en associations multiples, la galère des dataset pour avoir un objet qui va passer le save sans se bouffer des «*null on not nullable entity*» et autre joyeuseté*

C'est pour ça que je compte un test part propriété, même si il est évident q'au final ce sera un test par classe, le temps est proportionnel en gros au nombre de propriétés à tester