[C#][NHibernate] Générateur de classes

[Baptiste_87]

Salut,

Je me lance dans NHibernate, et créer chqaue classe à la main me paraît fastidieux... Je suppose donc que des gens beaucoup plus intelligent que moi ont déjà du faire des petits outils magiques qui font ça tout seul...
Je sais que ça éxiste pour le Java...

Avez-vous des noms pour ce genre d'outil (je n'ai pas été convaincu par mes recherches google...)

Merci davance

[iberserk]

Je me lance dans NHibernate, et créer chqaue classe à la main me paraît fastidieux... Je suppose donc que des gens beaucoup plus intelligent que moi ont déjà du faire des petits outils magiques qui font ça tout seul...
Je sais que ça éxiste pour le Java...

Modélisez votre base correctement puis Hibernate vous générera automatiquement les classes correspondantes.

[Baptiste_87]

Ma base de donnée est correctement modélisée. Par contre je ne vois toujours pas comment générer les classes automatiquement. Tous les tutos que j'ai pu lire pour découvrir NHibernate m'ont fait construire chacune des classes à la main.
Pouvez-vous m'éclaircir sur ce point?

Merci

[B.AF]

Mygeneration, le mapper nhibernate Lujan. Il est très bien fait !

En payant, il y a LLBL Gen Pro qui est très bien.
Moi j'utilise une version customisée du premier.

Dommage de partir d'une base; fait attention aux associations récursives

[iberserk]

Dommage de partir d'une base;

Question de point de vue

[B.AF]

Oui et non,

Partir d'une base et générer du code, c'est le meilleur moyen de faire des erreurs.

Modéliser le domaine, puis adapter sa persistence avec justement des implémentations SQL propres c'est plus long, mais dans le temps, c'est beaucoup plus fiable.

Et ça permet de prendre en considération les perfs dès le démarrage, de cache, de vues aussi.

Sachant qu'en outre la génération de code est rarement intelligente (au sens où elle ne fait pas de sélection fonctionnelle dans les relations ou dans les mappings); que le design de Db parfait n'existe pas, le temps gagné à générer du code est souvent gaspillé à se battre avec des pb de perfs et de chargement, qui finissent après par de la plomberie à n'en plus finir.

Un bon mapping dans mes critéres, c'est un mapping qui n'a jamais recours à du lazy loading, et où les relations matérialisées sont des graphes fonctionnellement identifiés.

Nombre des détracteurs de NHibernate ou d'Hibernate sont simplement des gens qui n'ont jamais compris que ce n'est pas parce qu'on génére des mappings automatiquement qu'ils sont justes et exploitable.
En outre, partir du domaine et travailler le mapping permet aussi de se familiariser avec certains concepts de Nhibernate (mutable, hèritage, projection, event, relations) qui sont souvent mal employés et posent pb.

[iberserk]

Partir d'une base et générer du code, c'est le meilleur moyen de faire des erreurs.

Ok et partir du code pour générer une base c'est le meilleur moyen de faire des erreurs une base de merd...

Débat inutile manifestement nous ne sommes pas daccord du tout... vous vous placez côté dev moi côté dba...

http://img1.lemondeinformatique.fr/f...s-epaisses.pdf

[iberserk]

Venant du dev.net à la base mon constat est vite fait... et beaucoups de mes developpeurs en reviennent...

[B.AF]

Envoyé par iberserk

Ok et partir du code pour générer une base c'est le meilleur moyen de faire des erreurs une base de merd...

Débat inutile manifestement nous ne sommes pas daccord du tout... vous vous placez côté dev moi côté dba...

http://img1.lemondeinformatique.fr/f...s-epaisses.pdf

Ah non, moi je ne suis pas partisan du "tout orm". Je dis juste que dans la réalité des pratiques; ceux qui partent d'une base et mappent n'y arrivent jamais. Ceux qui font un domaine et se posent les bonnes questions sur la base y arrivent.
Maintenant, je connais les positions de SQL Pro sur le sujet, mais là encore, c'est toujours pareil : il y a ceux qui utilisent l'ORM pour masquer des éléments qu'ils ne comprennent pas et ceux qui l'utilisent en connaissance de cause.
Acquérir cette connaissance, c'est plus simple sans générateur de code.
SQL Pro n'a pas une connaissance étendue des ORM donc son avis bien que très crédible est aussi biaisé. Si je ne connais que le Java et pas le SQL, mon tropisme serait de dire, vive l'épaisseur en Java.

Le terroriste c'est celui qui manipule des technos qu'il ne maitrise pas. Pas le fait d'en choisir une plus qu'une autre.

Typiquement, implémenter des vues, mapper des procs stocks...

[iberserk]

ux qui partent d'une base et mappent n'y arrivent jamais

La question est pourquoi?
Je ne remets pas en cause votre savoir faire sur de l'ORM etc et je félicite votre société si elle vous confit la mise en place de l'architecture, mapping etc...

Mais vous parlez de "réalité des pratiques" et bien là je rejoins SQL PRO: ce travail est rarement (ou trop rarement) confié à des gens compétent...

A vous de votre côté de ne pas généraliser les bienfaits de l'approche tout 'domaine' comme vous dites...
Peut être la maitrisez vous (manifestement...) mais combien de développeur à qui on va confier ces taches ne partiront pas dans les travers du lazy loading (par exemple) etc...

[B.AF]

Envoyé par iberserk

A vous de votre côté de ne pas généraliser les bienfaits de l'approche tout 'domaine' comme vous dites...
Peut être la maitrisez vous (manifestement...) mais combien de développeur à qui on va confier ces taches ne partiront pas dans les travers du lazy loading (par exemple) etc...

On ne se comprend pas. Je ne dis pas de faire le tout modèle, je dis :
- Partons d'une conception objet, avec des compétences appropriées
- Mappons la conception objet à une persistence, en vérifiant avec les DBA que la conversion objet / relationnelle est cohérente

• Utilisation des vues et contraintes
• Utilisation des procs stocks si nécessaire
• Indexation; clefs; ordres; check; types

- Généraliser le bridge Relationnel / Objet

• Types propriétaires
• Gestion des Id
• Gestion du versioning

- Utilisons le mapping et ses possibilités pour faire la liaison
- Utilisons les frameworks de tests pour toujours monitorer

• La clareté et l'efficience des requêtes SQL
• La taille des graphs d'objets
• La performance générale

- Créer une DAL propre

• Utiliser des requêtes pré-paramétrées validées tant que possible
• Utiliser des value object quand nécessaire
• Utiliser des sessions sans état pour les lectures
• Utiliser du plain SQL ciblé si nécessaire.

Pour moi c'est un travail long et commun. On ne doit pas utiliser un ORM sans avoir de sérieuses bases ou ressources DB locales.

[iberserk]

On ne se comprend pas

Cette fois ci c'est le cas et nous sommes daccord

[snopims]

tu peux utilisé AndroMda
(http://www.andromda.org/docs/andromd...net/index.html).
Il suffira de modéliser via de l'uml ton modèle objets, et il te genera le reste.