Discussion :

[Thomas.NET]

Bonjour à tous!

Je suis actuellement en phase de recherche pour un projet réalisé en ASP.NET et je me penche sur la question des ORM. J'ai effectué pas mal de recherches en essayant de trouver les points faibles et forts de chacun. J'ai également trouver des topics intéressants sur ce forum mais plus avancés dans la réflexion (comparatifs de performance etc.).

Deux ORM ont l'air de se dégager: l'utilisation de Linq to Entities via Entity Framework et NHibernate. Cependant le fait que EF4 soit actuellement en version Beta et les nombreuses critiques dont a fait l'objet la version précédente me rendent assez sceptique.

Cela m'aiderait beaucoup si vous pouviez m'aider dans mes recherches (j'ai cité deux ORM mais je suis totalement ouvert si vous avez des suggestions).

Je vous remercie par avance!

Thomas

[Pol63]

à en croire un débat sur ce forum, un dba a dit que les ORM c'est de la merde, ca casse les perfs par rapport à des méthodes classiques, mais qui demandent un connaissance du langage SQL et du sgbdr utilisé
donc en fait ca dépend du projet, pour un petit soft pas de problème en utilisant un ORM sinon il faut peut etre éviter pour un soft plus conséquent

tu ne précises d'ailleurs pas quel sgbdr tu veux utiliser, il parait qu'EF ne supporte qu'sql server
j'ai essayé EF sur le framework 3.5, et ca ne répond pas par exemple aux tables récursives
sinon c'est vrai que ca gagne du temps niveau développement

visual studio 2010 est actuellement en version RC, plutot stable et moins lent que les versions beta, EF4 y est surement intégré, je ne sais pas ce qu'il y a de nouveau à part des performances en plus dues à des requêtes générées de meilleure qualité

[chrisdot]

Je me suis penché sur ce problème pendant un petit bout de temps récemment. Jusque là nous utilisions un framework "maison", mais quand on copmmence à attaquer des clients RIA, on commence à se poser plus de question, puisqu'il faut pouvoir transporter toutes ces données...
Du coup, j'ai fait des tests avec NHibernate et EF4...
Pour faire court, NHibernate est très bien, par contre pour mettre en place le mapping san outils additionnels, c'est très galère à debbuger...
EF, au contraire (surtout la EF4) permet de faire pas mal de choses graphiquement, et d'arriver rapidement à qque chose.

Comme tout produit, on peut faire des critiques à EF4. Mais je pense que sa principale qualité est d'exister (ENFIN!!!)...
Pour moi, à présent, la question est plutôt comment intégrer une couche métier transportable à travers les N-tiers? (RIA services est trop "magique" à mon goût!!). Ensuite, le choix de l'ORM entre les 2 leaders, je ne sais pas, ça dépend de ses critères...

C'est certain qu'en écoutant certains DBAs, on n'utilise plus que des requêtes en dur (et si on écoute les développeurs de drivers, on n'utilise que de l'assembleur et éventuellement quelques lignes de C ). Mais en même temps on utilise pas des millions de données en même temps dans un modèle ORM. Les perfs ne sont pour moi pas vraiment le facteur clé dans l'histoire. C'est la clarté et le maintenabilité du code qui prime pour nous développeurs... Ensuite bien sûr, je comprends que les DBAs qui travaillent avec des millions d'enregistrement à la fois n'utilisent que des requêtes!!

Sinon, suis pas certain de ce qu'avance Pol63 . Il suffit que tu aies un provider ADO .NET pour que l'EF supporte ton SGBDR comme le spécifie la liste ci-dessous. N'as-tu pas confondu avec Linq to SQL?

[Pol63]

Sinon, suis pas certain de ce qu'avance Pol63 . Il suffit que tu aies un provider ADO .NET pour que l'EF supporte ton SGBDR comme le spécifie la liste ci-dessous. N'as-tu pas confondu avec Linq to SQL?

si peut-être


sinon pour "les perfs on s'en fout" je suis moyennement d'accord
quand au bout de 3 ans d'utilisation ton système qui marchait super bien au début devient plus que lent, le client se plaind, et une analyse des pertes de perf est faite
il faut alors modifier du code et du coup la maintenabilité du code elle disparait !

[chrisdot]

sinon pour "les perfs on s'en fout" je suis moyennement d'accord
quand au bout de 3 ans d'utilisation ton système qui marchait super bien au début devient plus que lent, le client se plaind, et une analyse des pertes de perf est faite
il faut alors modifier du code et du coup la maintenabilité du code elle disparait !

C'est pas exactement ce que j'ai dit. J'ai juste dit que pour de la consultation d'enregistrement par enregistrement (typiquement les applis de gestion), c'est pas le facteur principal l'optimisation de la requête: de passer de 2ms à disons 10ms au niveau d'une requête, l'utilisateur final ne verra pas la différence... (avec le transport et tout ce qui va avec, c'est noyé...) Par contre pour mettre à jour un champs dans 1000000 enregistrement, évidemment l'oRM n'est pas adapté!!)

[oyigit]

Perso, je penche plutôt pour l'EF. Il y a certes des limitations, certaines chose non supporté, mais pour avoir tester Nhibernate et EF je sais que les deux ont des limitations, des lacunes... En revanche, l'intérêt de l'EF est le gain de temps en développement, et tu peux fanchement faire pas mal de chose. Avec un peu d'expérience tu sauras rapidement les choses à faire et ne pas faire. De plus, l'EF est supporté entièrement par Microsoft. Avec l'EF, ta source de données est IQueryable, et supporte beaucoup de requête Linq (à mon avis l'une des meilleurs avancés ces dernière années). Pour certaines requêtes complexe, tu peux facilement passer par des vues et les ajouter à ton model...
Nhibernate quand à lui est un produit aussi très bien. Il permet bcp plus de liberté au niveau du mapping objet relationnel.

Perso je pense plutôt pour l'EF...

[Pol63]

et les IQueryable comme les IEnumarable permettent d'avoir des perfs en plus, tu peux les modifier plein de fois, les compléter etc... l'exécution n'est faite qu'une fois et au moment de l'évaluation des données

[chrisdot]

Suis d'accord avec toi oygit. (En ce qui concerne Linq entre autre, à noter cependant que NHibernate supporte à présent aussi Linq!!)

[oyigit]

(En ce qui concerne Linq entre autre, à noter cependant que NHibernate supporte à présent aussi Linq!!)

Je n'ai pas encore eu la chance d'évaluer la version IQueryable d'Nhibernate. Je pense néamoins qu'il est plus judicieux de travailler avec l'EF, car fournit par Microsoft pour bosser sur un EDI Microsoft. Et n'aller pas croire que je suis pro Microsoft, mais je trouve plus logique d'utiliser l'EF dans un projet C# ou VB.Net

[meziantou]

Je pense que EF4 est une bonne solution. Surtout un gain de productivité enorme grace aux T4. Pour vous en convaincre je vous conseille de regarder le blog de Matthieu Mezil.

Autrement il existe aussi CodeFluent (ce n'est pas un ORM) mais c'est très puissant pour l'accès aux données.
http://www.codefluent.com/PortalDefault.aspx?id=38

[chrisdot]

Personnellement je pense que c'est surtout le choix d'une couche métier stable (maison ou non) qui est important et qui va apporter le gain de productivité.. Genre CSLA...
En partant sur une couche métier éfficace, je pense qu'on se pose moins de questions quant à l'accès à la base. (suis en train de tester tout ça)

[Louis-Guillaume Morand]

Personnellement je pense que c'est surtout le choix d'une couche métier stable (maison ou non) qui est important et qui va apporter le gain de productivité.. Genre CSLA...
En partant sur une couche métier éfficace, je pense qu'on se pose moins de questions quant à l'accès à la base. (suis en train de tester tout ça)

oui mais la couche métier est importante surtout quand le projet évolue vite. Si le modèle change, il faut que coté code l'ORM s'adapte rapidement sans avoir d'incidence sur la couche métier.

moi je kiffe Entity. de plus il est simple et facilement extensible (NHibernate me donne encore envie de vomir, BllToolkit est bien mais faut tout faire à la main).

[B.AF]

Du coup, j'ai fait des tests avec NHibernate et EF4...
Pour faire court, NHibernate est très bien, par contre pour mettre en place le mapping san outils additionnels, c'est très galère à debbuger...
EF, au contraire (surtout la EF4) permet de faire pas mal de choses graphiquement, et d'arriver rapidement à qque chose.

Moi j'aimerai que tu arrêtes de dire des absurdités.
Déjà aujourd'hui il y a aussi un Mapper Fluent, et si tu savais t'en servir tu saurais qu'à priori, le mapping graphique c'est une perte de temps et ça n'a rien à voir avec le debuggage.

C'est ridicule de dire "prenez cet outil, il a un designer graphique".

Pire, hibernate permet aujourd'hui grace a une interface fluide de faire du mapping en utilisant des lambdas et du c#, donc de les contrôler en codant et pas à la génération.

Que tu ne comprennes pas, soit, mais que tu dénigres en disant des absurdités, non.

[B.AF]

oui mais la couche métier est importante surtout quand le projet évolue vite. Si le modèle change, il faut que coté code l'ORM s'adapte rapidement sans avoir d'incidence sur la couche métier.

moi je kiffe Entity. de plus il est simple et facilement extensible (NHibernate me donne encore envie de vomir, BllToolkit est bien mais faut tout faire à la main).

L'objectivité des MVP ....

[chrisdot]

Moi j'aimerai que tu arrêtes de dire des absurdités.
Déjà aujourd'hui il y a aussi un Mapper Fluent, et si tu savais t'en servir tu saurais qu'à priori, le mapping graphique c'est une perte de temps et ça n'a rien à voir avec le debuggage.

[...]

Que tu ne comprennes pas, soit, mais que tu dénigres en disant des absurdités, non.

Ca serait bien que tu lises avant d'incendier les gens et de me faire dire ce que j'ai pas dit. J'ai dit sans outils additionnels...
J'ai juste dit que je suis arrivé plus rapidement à quelque chose qui me convienne avec EF puisque tout est intégré et que je ne suis pas un Dieu de NHibernate comme toi.
Attention si tu vois le mal partout, il faut plus discuter avec les gens.

[Louis-Guillaume Morand]

pourquoi parce que j'ai un logo, tu me juges sur cela.
mon objectivité est basée sur mon expérience. j'utilise NHibernate depuis ses premières versions avec ses configs XML à deux balles et je l'utilise encore pour une question d'existant.

Il fait ce que je veux mais parfois j'aurais plus vite d'écrire ma requête en dur dans le code pour obtenir le même résultat. Me palucher des fichiers de config XML, (à l'époque, les surcouche type Castle, ca n'existait pas), simplement pour faire une requête scalaire, je trouve cela abusé.

qu'il soit complet et extensible ok, j'ai pas dis le contraire mais il n'en reste pas moins lourd, comparé à d'autres solutions.
que tu ne sois pas complet avec mon opinion, ca me va, mais que tu dénigres mon avis parce que tu me penses moins objectif que toi, non. Pareil pour l'opinion des autres. Tu es sur un forum public, t'es pas un dieu, juste un technique, comme moi, comme lui, comme les autres donc soit tu respectes les autres, soit tu vas ailleurs. Tes réponses et ton expertise sont appréciés et tu peux critiquer la réponse d'un autre, mais tant que c'est fait avec respect et sans se prendre pour le meilleur

ps: si tu veux continuer à débattre, ca sera par MP. ici c'est un débat technique. Les opinions personnelles hors technique, n'y ont pas leur place!

[B.AF]

Bonjour à tous!

Je suis actuellement en phase de recherche pour un projet réalisé en ASP.NET et je me penche sur la question des ORM. J'ai effectué pas mal de recherches en essayant de trouver les points faibles et forts de chacun. J'ai également trouver des topics intéressants sur ce forum mais plus avancés dans la réflexion (comparatifs de performance etc.).

Deux ORM ont l'air de se dégager: l'utilisation de Linq to Entities via Entity Framework et NHibernate. Cependant le fait que EF4 soit actuellement en version Beta et les nombreuses critiques dont a fait l'objet la version précédente me rendent assez sceptique.

Cela m'aiderait beaucoup si vous pouviez m'aider dans mes recherches (j'ai cité deux ORM mais je suis totalement ouvert si vous avez des suggestions).

Je vous remercie par avance!

Thomas

Voilà ce qui s'est passé :

Nous avons une couche DAL sous Nhibernate qui utilise le mapping fluent (on perd moins de temps qu'avec un designer graphique, il y a l'intellisense sur le mapping), et Linq.

Nous utilions le log et les intercepteurs pour généraliser les fonctions suivantes :
Tests unitaires
Verification de la qualité du SQL

Nous avons ecrit une partie de notre dialect SQL pour otpimiser le dialect 2008 par défaut, et la génération des shémas conformément aux demandes de notre Dba.

Nous avons implémenté un cache distribué qui est extrêmement bien géré et apporte un vrai gain dans l'application.

L'intégralité de nos objets ont ainsi pu être séparé dans différentes couches :
Value Objects, Read Only...

La possiblité de paramétrer le framework nous a permis d'avoir d'excellentes performances (session sans état avec objets en lecture seule qui nous améne proche du data reader en perfs)

Nous avons une base de 4500 objets persistants, sur des bases de x00 go de données, oracle ou sql server.

Avec EF, nous ne pouvons même pas compiler les code sur cette volumétrie.

Comme quoi, entre la théorie des tutos et la réalité du dev...

Pour être honnête sur un petit projet, EF fait l'affaire parce que tu n'auras pas trop besoin de mettre les mains dans la plomberie. Pour une projet lourd et long, c'est pas suffisant, il est tout seul, peut d'extensibilité, et surtout un côté boite noir et ré-invention de la roue agaçant.

Tout dépend de ce que tu veux faire.
NHibernate est un outil complexe, qui fait vraiment du DDD, et la plupart des gens qui pensent qu'il "suffit de générer du code" font faces à des problèmes de connaissance.
L'important est surtout que tu comprennes les enjeux d'exploiter un ORM sur une architecture.

Si tu veux j'ai une grille d'évaluation d'ORM sur des fonctionnalités sur des archi distribuées multi tiers physique.

[B.AF]

pourquoi parce que j'ai un logo, tu me juges sur cela.
mon objectivité est basée sur mon expérience. j'utilise NHibernate depuis ses premières versions avec ses configs XML à deux balles et je l'utilise encore pour une question d'existant.

Il fait ce que je veux mais parfois j'aurais plus vite d'écrire ma requête en dur dans le code pour obtenir le même résultat. Me palucher des fichiers de config XML, (à l'époque, les surcouche type Castle, ca n'existait pas), simplement pour faire une requête scalaire, je trouve cela abusé.

qu'il soit complet et extensible ok, j'ai pas dis le contraire mais il n'en reste pas moins lourd, comparé à d'autres solutions.
que tu ne sois pas complet avec mon opinion, ca me va, mais que tu dénigres mon avis parce que tu me penses moins objectif que toi, non. Pareil pour l'opinion des autres. Tu es sur un forum public, t'es pas un dieu, juste un technique, comme moi, comme lui, comme les autres donc soit tu respectes les autres, soit tu vas ailleurs. Tes réponses et ton expertise sont appréciés et tu peux critiquer la réponse d'un autre, mais tant que c'est fait avec respect et sans se prendre pour le meilleur

ps: si tu veux continuer à débattre, ca sera par MP. ici c'est un débat technique. Les opinions personnelles hors technique, n'y ont pas leur place!

Dans ce cas, le fait de "vomir avec Nhibernate" était "mon objectivité est basée sur mon expérience"...Excuses moi je n'avais pas compris....

[B.AF]

Ca serait bien que tu lises avant d'incendier les gens et de me faire dire ce que j'ai pas dit. J'ai dit sans outils additionnels...
J'ai juste dit que je suis arrivé plus rapidement à quelque chose qui me convienne avec EF puisque tout est intégré et que je ne suis pas un Dieu de NHibernate comme toi.
Attention si tu vois le mal partout, il faut plus discuter avec les gens.

Je demande juste à ce que vous arrêtiez de dire n'importe quoi du travail GRATUIT de gens biens fondés sur des critéres absurdes.

Je ne vois pas le mal, je ne suis pas un dieu de Nhibernate, j'essaye juste de faire preuve d'objectivité. Et connaissant la plupart des membres du projet, je ne peux pas laisser dire des absurdités.

Oui EF et Nhibernate sont comparables mais sur des critéres techniques.
Dire que tu ne peux pas débugger Nhibernate qui est livré avec ses sources, et que tu as choisi EF qui lui n'est pas livré avec ses sources, ca peut quand même porter à critique.

[B.AF]

Concernant les mappings :
Interfaces Fluides

Concernant les requêtes :
Query Over et Lambdas

Concernant Linq :
Linq Nhibernate

utiliser Log4Net dans Hibernate:
Trace et Log

utiliser les fameuses T4 pour générer du NHibernate
Sharp Architecture

Utiliser les events et Listeners pour produire sa propre analyse :
http://www.codinginstinct.com/2008/0...listeners.html

Le produit a évolué depuis le Framework 1.1 (.Net aussi d'ailleurs).
Certaines fonctionnalités sont des héritages du passé; et au moment où elles sont sorties, elles étaient la meilleure alternative.



Et pareil pour EF. Dont j'attends la V4 avec grande impatience, car je crois à l'utilité pour une communauté d'avoir plusieurs solutions. (Même si je n'aime pas les T4).

Je plussoie aussi fortement code fluent, qui a une vraie usine de génération, qui utilise un pattern active record, mais qui est basé sur des procs stocks, et qui n'est pas une vraie logique d'ORM.
En revanche, leur approche par les modéles est excellente !