Outil de mapping objet/relationnel OR not ?

A tout ceux qui utilise une architecture en couche sous DotNet (ou qui s'y interresse...)

Après avoir errer de longues heures sur dvp, j'ai vu de nombreuses personnes utilisant des outils de mapping objet/relationnel (ORM), et d'autres qui préférent gérer cela manuellement (avec les outils d'ADO.NET). Je n'ai pas pu rééllement synthétisé les avantages et les inconvénients de ces 2 méthodes.

Certains d'entre vous vont certainement me dire que cela depend des besoins, et ils auront raisons ! ;) Et bien allons-y si vous le voulez bien : détaillons à quels besoins ces solutions répondent le mieux.

Personnellement, j'utilise ma propre dll de mapping et je n'ai même pas pensé utiliser un outil par ce que ce genre d'outil ne te donne pas la liberté de faire ce que tu veux (et il faut dire que je n'ai même pas essayer, je pense que ce genre d'outils n'est jamais efficace et que chaque application devra avoir son indépendance ...)
enfin je pense que j'ai fait un bon choix puisque je peux tout gérer avec ma dll, en plus elle est évolutive, ...

Je suis globalement d'accord avec toi mais peut-être pas tout a fait pour les mêmes raisons. Le point principal me semble être la possibilité d'avoir une couche métier orienté objet (héritage et polymorphisme). Ca doit exister mais je n'ai vu aucun outil le gérer (il faudrait qu'il intégre un modélisateur UML, par exemple).

Si ce besoin n'est pas clairement défini, et que l'on a le temps de choisir et de prendre en main un bon outil de mapping ORM, j'ai l'impression que ce peut être rééllement trés avantageux...

J'ai testé NetTiers qui me semblent être simple et relativement efficace mais perso je ne compte l'utiliser que comme source d'inspiration, vu que je souhaite une couche métier orienté objet.

L'utilisation ou pas d'un ORM dépend en grande partie de l'ordre dans lequel on concoit l'application.

Si on concoit d'abord la base de données, alors on a tendance a créer des classes qui correspondent aux tables. Du genre 1 table -> 1 classe, 1 enregistrement -> 1 instance, 1 champ -> 1 attribut. Dans ce cas, il vaut mieux faire le mapping a la main avec ADO et des requetes simples (new=INSERT, ...)

Si on concoit d'abord les classes, alors on est confronté au problemes d'impédence: comment représenter l'heritage, la composition et le polymorphisme dans une BdD relationnelle ? Dans ce cas, un bon ORM vous simplifie énormément le travail

c'est un sujet trés vaste,

il y a un choix a faire entre les deux solution, développer sa propre couche de données ou utilisé les outils d'ORM.
chacune à ces propres avantages. si on prévoi de développé un framework avec des générateurs alors la solution de construire sa propre couche de données.

sinon on utilise des outils d'ORM là encore le choix de l'outil est un autre sujet.
personnelement j'ai travaillé avec c'est deux solution dans un projet java avec l'outil hibernate dans un projet DotNet avec l'outils nhibernate et dans un autre projet dotnet avec notre propre couche de données.
mais pour les outils nhibernate et hibernate j'ai créé une autre couche qui spécufique a mon frmework donc je pense que c'est la meilleure solution avec l'utilisation des outils de génération des fichiers de mappage O/R.

Justement, le 1er chapitre de NHibernate in Action discute longuement ce sujet; vous pouvez le télécharger gratuitement sur manning.com/kuate :)
Faites moi savoir ce que vous en pensez...