NHibernate possède plusieurs niveaux de cache ce qui peut le rendre très efficace. Le problème avec cet outil c'est qu'ils est assez complexe à configurer correctement et la doc sur NHibernate est une vaste blague!
Version imprimable
NHibernate possède plusieurs niveaux de cache ce qui peut le rendre très efficace. Le problème avec cet outil c'est qu'ils est assez complexe à configurer correctement et la doc sur NHibernate est une vaste blague!
Voici les perfs du fournisseur NHibernate:
Les requêtes SQL sont correctes, mais quand je regarde SQL Server Profiler, elles sont envoyées à un rythme très faible. J'ai l'impression que beaucoup de temps est perdu lors du mapping.
Je n'ai jamais fait de benchmark si c'est la question !Citation:
Envoyé par Immobilis
Simplement par retours d'expérience je sais que NHibernate, quand il est bien configuré, a globalement de meilleurs performances que Entity Framework, (sauf peut-être pour de la lecture).
C'est le problème, même si je suis convaincu qu'un expert NHibernate trouverait plein de trucs à changer dans ce code, et dans le paramétrage de NHibernate qui te permettraient d'améliorer celà.Citation:
Envoyé par Immobilis
C'est assez difficile d'avoir des chiffres comparables.Citation:
Envoyé par Immobilis
En gros, ce que je peux te dire, c'est que le rapport :
Temps passé à configuré + Temps passé à développé
---------------------------------------------------
Performances obtenues
est bien meilleur pour Entity Framework. Mais certaines fois, les performances que tu obtiens justifient le surcoût.
Comme je n'ai jamais utilisé NHibernate avant, j'imagine que beaucoup d'utilisateurs le configureraient comme moi. C'est un peu décevant de voir des perfs aussi mauvaises dans une configuration de base.
Si quelqu'un voit des moyens d'améliorer le fournisseur, je peux faire d'autres tests.
Bonjour à tous,
Citation:
Comme le montre le benchmark d'Immobilis, Entity Framework n'est pas très performant à l'écriture, mais se débrouille plutôt bien en lecture.
Comme glissé à Immobilis par MP parallèlement à son article de Benchmark, j'ai envi de dire que pour ma part, c'est tout ce que je demande à EF:Citation:
En gros, pour utiliser dans une appli web basique, c'est vraiment bien.
En revanche, pour faire tourner des batchs de facturations, là c'est un choix un peu plus discutable...
Mapper mes objets dans le cadre de SELECT, cela fait gagner un temps fou lors de la phase de DEV...
Dès que plusieurs lignes sont à traiter, c'est automatique: passer le C UD en procédure stockée lancées par EF et le tour est joué...
Ce n'est pas lié à une faiblesse des ORMs mais au fait que le code client (entendez CSHARP) ne peut pas traiter de manière ensembliste un jeu de données...
Donc l'idéal pour moi :
C+U+D en procédure stockée
R laissé à EF et LINQ TO SQL...
+1Citation:
Envoyé par iberserk
Et encore. La lecture peut aussi être faite sous forme de procédure stockée. Mais bon, difficile d'avoir des procédures pour chaque cas d'utilisation suivant qu'on souhaite faire remonter plus où moins de champs.
En fait vous feriez plutôt des fonctions SQL de type table qui peuvent prendre en entrée des paramètres et qui vous retourne une table.Citation:
Et encore. La lecture peut aussi être faite sous forme de procédure stockée. Mais bon, difficile d'avoir des procédures pour chaque cas d'utilisation suivant qu'on souhaite faire remonter plus où moins de champs.
Vous pouvez ainsi faire comme ceci:
Avantage: celà vous retourne un IQUERYABLE qui peut donc 'subir' du LINQ TO SQL derrière, contrairement à une procédure stockée qui vous retournera une exception si vous faites ne serait-ce qu'un COUNT() dessus...Code:
2