Ma société est en train de réécrire une application existante à partir de zéro. Cette application, entre autres tâches, effectue des requêtes SQL complexes contre les données de commande et de facturation afin de produire des rapports de vente. Les requêtes sont construites de manière dynamique en fonction de laquelle les critères sont sélectionnés par l'utilisateur, afin qu'ils puissent être assez complexes si de nombreux critères sont sélectionnés. Actuellement, la performance est décente, mais pas géniale.
Maintenant, pour la nouvelle version, nous aimerions utiliser un orj, probablement NHibernate, car il est apparemment le seul qui prend en charge Oracle Lite (l'application utilise Oracle ou Oracle Lite, selon qu'il fonctionne en mode connecté ou déconnecté. ). Mais je suis inquiet de la performance des requêtes générées par NHibernate. J'ai déjà travaillé avec d'autres orateurs avant (Linq à SQL SQL, Framework), mais les requêtes étaient assez simples, il n'y avait donc pas de problème de performance.
Donc, avant de prendre une décision sur l'utilisation d'une orje ou de rester avec un SQL uni, j'aimerais savoir à quel point ces outils traitent des scénarios tels que des jointures extérieures, des sous-requêtes, etc. Pensez-vous à un or. NHibernate) convient à une utilisation dans le scénario de rapport décrit ci-dessus? Devrais-je m'inquiéter des performances des requêtes complexes?
Tous les commentaires seraient grandement appréciés
3 Réponses :
NHibernate a un peu une courbe d'apprentissage, mais cela vaut la peine d'apprendre comme tout le temps passé à payer plusieurs fois. Je recommanderais NHibernate dans un livre d'action pour apprendre comme une excellente ressource et couvre tout ce que votre question demande et beaucoup plus.
Les performances NHibernate peuvent être réglables (voir Liens ci-dessous) et NHibernate a un mécanisme de mise en cache robuste.
http://www.codeproject.com/kb/database/nhibernate_perf.aspx https://www.hibernate.org/hib_docs/nhibernate/html/performance. HTML
En fin de compte, les performances seront déterminées par qui écrit les requêtes telle qu'elle est dans SQL.
Merci pour le conseil, cela a l'air intéressant
Je mentionnerais également la série Screencast "Summer of Nhibernate" - la seule raison que j'utilise aujourd'hui! Steve Bohlen fait un excellent travail à travers tous les détails de Nhibernate! Summerofnibernate.com
Si vous recherchez Orm avec traducteur LINQ complet et efficace, je vous recommande d'essayer cadre d'entité ou dataObject.net . Je ne suis pas sûr du support Oracle Lite. Le traducteur Linq de Nhibernate n'est pas encore complètement fini.
Quoi qu'il en soit, la meilleure chose à faire est de télécharger des outils d'ormes de premier plan et de les tester sur des requêtes difficiles avec le regroupement, la jonction, les sous-requêtes, etc.
Merci pour votre réponse. Malheureusement, EF n'est pas une option (bien que cela aurait été mon premier choix). Il existe des fournisseurs EF pour Oracle (Devart, DataDirect), mais pas pour Oracle Lite, et il n'y en aura probablement jamais un parce que Oracle Lite n'est pas largement utilisé. Et DataObject.net ne supporte pas encore l'oracle ...
voir ce graphique . Il n'y a pas de dataObjectS.NET pour l'instant, mais ses résultats en comparaison avec EF et NHibernate sont affichés Ici .
code de test LINQ pour EF est ici ; Des versions pour d'autres outils peuvent être trouvées dans le même dossier. Tous ces fichiers .cs sont générés par Un seul modèle T4 , Les tests sont donc entièrement identiques. Modèle utilisé il y a Northwind.
Peu de plus de liens:
Quelques autres liens: Fabiomaulo.blogspot.com/2009/09/ pourquoi-don-choose-nhibernate.ht ml et fabiomaulo.blogspot.com/2009/08/... :)
Alex, merci, ce site a l'air vraiment prometteur! Maintenant, je dois passer du temps à disséquer les résultats des tests;)
En ce qui concerne les requêtes complexes: Ici, tout dépend de la qualité du traducteur LINQ. Le traducteur NH Linq semble entièrement redressé - en avant lorsqu'il fonctionne. Notez que ces tests montrent ce qu'un orme particulier peut traduire traduire, mais pas comment . Tests de performance Il est conçu pour des requêtes simples, vous ne devriez donc pas les étudier sérieusement. Bien que par exemple Les tests de pagination montrent une différence de qualité de la traduction: certains fournisseurs utilisent toujours rive-numéra au lieu de haut, et c'est la raison principale qu'ils perdent sur ce test.
En ce qui concerne les messages de Fabio: En fait, je les ai commentés dans ORMBattle.net Blog. Sa comparaison n'était pas du tout honnête: ormbeTattes.net/index.php/blog/...
Eh bien, autant que j'aimerais, je ne pourrai pas utiliser EF sur ce projet. La comparaison entre EF et NH n'est donc pas vraiment pertinente pour moi ... Quoi qu'il en soit, je pense que le seul moyen de devenir pertinent Les données de performance pour mon scénario particulier consiste à faire mes propres tests avec les requêtes réelles que mon application fera ...
Oui, c'est probablement la seule sortie. La traduction LINQ a beaucoup d'aspects, il semble donc presque impossible de comparer la qualité de la traduction "en général".
Y a-t-il une version plus récente du tableau? Un grand nombre peut être atteint à cette époque.