nhibernate : Avez vous développé vos propres toolkit dans le cycle de dev ?

La multiplication des couches dans le développement d'application en lien avec des bases de données amène un peu de complexité... Heureusement des framework comme nhibernate s'occupent à notre place de pas mal de tracasseries.

Mais pour aller plus loin et accélérer le développement, je me surprends actuellement à rêver du "toolkit idéal" qui pourrait permettre :

De concevoir le MCD, d'en générer le MPD et pourquoi pas également une base des "classes entités" ainsi que les fichiers de mapping ? *
Avec la possibilité de personnaliser les spécificités de ces différents types de modélisations...

Avez vous recours à différents logiciels pour réaliser ces étapes ? Si c'est le cas ou si vous écrivez vous même une grande partie du code, n'êtes vous pas gênés en cas de modification à apporter au MCD ou aux classes ? (effets de bords non repérés sur des shémas complexes, bugs...)

... ou bien avez vous développé votre propre toolkit .net rendant possible la conception/modification (éventuellement graphique) des différentes modélisations ? (MCD, MPD, Classes Entités, fichiers de mapping) ? **

Merci pour le retour de vos expériences et pratiques ;)

* : j'ai présenté la conception du MCD en premier car c'est chose courante de procéder ainsi ; maintenant rien ne dit qu'il s'agisse e la meilleure méthode

** : j'exclue bien entendu les classes traitant de la logique métier

Dans ma boite, on utilisait jusqu'à peu une solution développée en interne pour l'ORM. La solution vieillissant, on passe peu à peu à Linq to SQL.

Salut,

Tout d'abord, excusez moi pour mon français- elle est loin d'être suffisant, mais j'essaye au moins...
Pour moi, la meilleur solution pour travailler avec NHibernate c'est créer votre propre template d'un outil de code generation- MyGeneration est considérer comme le plus stable et fiable, et vous pouvez toujours prendre une template existante et le modifier.
Le solutions toutes faite (et payants), a mon avis, ne sont pas toujours vraiment adoptable pour un vrai projet complexe- elle peuvent être trop envahissants ou manquer les options le plus importants pour vous.

Ce que je peux en tous cas vous proposer c'est de jeter un coup d'œil sur le windsor container et les autres outils du castle project, et penser de travailler avec leur Mapping attributes, qui facilite le travaille en supprimant les fichier hbm - ça devient nettement plus simple de diriger les changements puisque tout s'est trouve dans le même place, dans vos POCOs.

Sinon, quand vous parlez de "effets de bords non repérés sur des shémas complexes, bugs..." lors des modifs de classes, qu'est ce que vous voulez dire exactement par ça? les classes eux même ne doivent jamais changer, sauf dans le cas de changement de chema de la base, ou plus spécifiquement de la table mappé par la classe. Pour moi, ceux classes doivent avoir seulement les propriétés de mapping et rien d'autre! Quand on change le chema de la base peu importe l'ORM ou la couche d'accès au données que vous avez, il y aura de dégât à défaire le plus que vous êtes avancé dans votre projet...

my two pence.. :)

Merci pour toutes ces précisions, j'ai commencé à me documenter sur les outils que vous avez listé.

Citation:

---

Envoyé par CSharper

Sinon, quand vous parlez de "effets de bords non repérés sur des shémas complexes, bugs..." lors des modifs de classes, qu'est ce que vous voulez dire exactement par ça? les classes eux même ne doivent jamais changer, sauf dans le cas de changement de chema de la base, ou plus spécifiquement de la table mappé par la classe. Pour moi, ceux classes doivent avoir seulement les propriétés de mapping et rien d'autre! Quand on change le chema de la base peu importe l'ORM ou la couche d'accès au données que vous avez, il y aura de dégât à défaire le plus que vous êtes avancé dans votre projet...

---

Oui c'est surtout dans ce dernier cas que je m'interrogeais sur des toolkit maison capables d'automatiser certaines tâches... dans le cas d'un passage d'une relation 1:n à n:m par exemple. Cela implique le changement en cascade de 3 couches en cascade : 1) script sql de modification de la structure de la base de données , 2) modification du code de la classe, 3)modification des propriétés de mapping

Citation:

---

Envoyé par georgeduke

dans le cas d'un passage d'une relation 1:n à n:m par exemple. Cela implique le changement en cascade de 3 couches en cascade : 1) script sql de modification de la structure de la base de données , 2) modification du code de la classe, 3)modification des propriétés de mapping

---

Pour moi il y a deux genres de modifications (pour simplifier): quand on modifie le type ou nom d'une colonne / propriété ou quand on modifie/ajoute/supprime une table entière. Le premier je fait normalement manuellement- surtout si je travaille avec les Mapping attributes de NHibernate (ou ActiveRecord de castle project). Ces deux peuvent créer la base pour toi, donc le script sql ne me gêne plus, et les modifs sont faites dans le même endroit - dans mon domain object.
Pour les plus grandes modifications, j'utilise effectivement un outil pour générer au moins le domain object, en utilisant une template que j'ai écrit moi même. Vous pouvez essayer MyGeneration ou SmartCode. Si ça vous intéresse, vous pouvez voir un vieux template à moi pour Smart Code et le modifier pour vos besoins...

ça fait combien de temps que vous travailler avec NHibernate? Êtes vous content avec cette ORM? Pour quelle projet (si je peux demander?)- vous pouvez m'envoyer un message si vous préférez... :)

Personnellement, j'ai développé mon propre outil à l'occasion d'un projet qui nécessitait de gérer des données complexes (plusieurs tables, triggers, checks...) et qui devait permettre d'enregistrer les données sous un format fichier.

A l'heure actuelle, on ne peut pas vraiment parler d'outil de mapping. C'est plus une sorte de mini-SGBDR intégré directement dans le code et gérant une unique connexion (logique, puisqu'il s'agit de gérer des données comme le ferait word, excel, etc).
Par contre, en dehors de cette restriction, j'ai tous les avantages d'un SGBDR moderne : transactions imbriquées, triggers, checks, clefs étrangères, héritage de table...
Ca me permet finalement d'enregistrer les données dans un format xml compressé, à la manière d'openxml. Bref...

J'ai développé ça avant la sortie de Linq, alors j'espère trouver du temps pour le porter sur Linq et étendre ses possibilités : l'idéal serait d'obtenir une sorte de "Linq to Everything" (xml, sql, webservices, en gros).