La plupart de ce que j'entends sur le chargement paresseux de Nhibernate, c'est qu'il vaut mieux l'utiliser que de ne pas l'utiliser. Il semble que tout semble de minimiser l'accès à la base de données, dans le but de réduire les goulots d'étranglement. Mais peu de choses viennent sans compromis, il limite certainement légèrement la conception en vous forçant à avoir Cela me fait me demander s'il existe des situations définies dans lesquelles les performances d'accès aux données sont blessées en utilisant le chargement paresseux.
Donc je me demande, quand et dans quelles situations dois-je éviter la chargement paresseux l'un de mes objets de NHibernate-persistés?
est l'inconvénient de charger des paresseux simplement dans un délai de traitement supplémentaire, ou peut-on nibrer de paresseux-chargement à augmenter l'heure d'accès aux données (par exemple, en effectuant des retours round supplémentaires dans la base de données)?
Merci! propriétés virtuel. Mais j'ai également remarqué que certains développeurs tournent de paresseux sur certains objets souvent utilisés.
5 Réponses :
La version courte est ceci:
Au cours des dernières années, nous nous concentrons sur les délais de développement rapides. Maintenant que nous avons une application solide et UserBase, nous optimisons notre accès aux données.
Les performances totales peuvent être meilleures, mais parfois les charges de graphique d'objet de grande taille peuvent affecter les performances apparentes , ce qui peut parfois être un contrat plus important aux utilisateurs.
Excellent point. Charger les bases. Affichage. Ajax dans des valeurs traversées selon les besoins. (par exemple).
Le compromis habituel pour la chargement paresseux est que vous faites un succès plus petit sur la base de données à l'avant, mais vous finissez par faire plus de coups à long terme. Sans chargement paresseux, vous attrapez un objet d'objet entier à l'avant, aspirant une grande partie de données à la fois. Cela pourrait potentiellement causer un retard dans votre assurance-chômage, et il est donc souvent découragé. Toutefois, si vous avez un graphique d'objet commun (pas seulement un seul objet - sinon ce n'aurait pas d'importance!) Que vous savez être accessible fréquemment, et de haut en bas, il est logique de le retirer à la fois.
À titre d'exemple, si vous faites un système de gestion des commandes, vous ne supprimerez probablement pas toutes les lignes de chaque commande, ni toutes les informations clientes, sur un écran de résumé. Le chargement paresseux empêche cela de se produire.
Je ne peux pas penser à un bon exemple de ne pas l'utiliser hors tension, mais je suis sûr qu'il y a des cas où vous voudriez faire une grosse charge d'un graphique d'objet, disons, sur l'initialisation de l'application, afin de Évitez les retards dans le traitement davantage sur la ligne.
Il existe des compromis de performance clairs entre des objets de chargement avides et paresseux d'une base de données.
Si vous utilisez un chargement impatient, vous aspirez une tonne de données dans une seule requête, que vous pouvez alors cacher. Ceci est le plus courant sur le démarrage de l'application. Vous négociez une consommation de mémoire pour les voyages de la base de données.
Si vous utilisez un chargement paresseux, vous aspirez une quantité minimale de données dans une seule requête, mais à tout moment, vous avez besoin de plus d'informations relatives à ces données initiales, il nécessite davantage de questions sur la base de données et les hits de performance de la base de données sont très souvent la performance majeure. goulot d'étranglement dans la plupart des applications.
Donc, en général, vous souhaitez toujours récupérer exactement les données dont vous aurez besoin pour l'ensemble " Unité de travail ", pas plus, pas moins. Dans certains cas, vous ne savez peut-être pas exactement ce dont vous avez besoin (car l'utilisateur fonctionne à travers un sorcier ou quelque chose de similaire) et dans ce cas, il est probablement logique de faire la charge paresseuse que vous allez.
Si vous utilisez une orje et que vous vous êtes concentré sur l'ajout de fonctionnalités rapidement et que vous reviendrez et optimisera les performances plus tard (ce qui est extrêmement courant et un bon moyen de faire des choses), avoir une chargement paresseuse, la valeur par défaut est la bonne voie. Si vous trouvez ultérieurement (via le profilage de performances / analyse) que vous avez une requête pour obtenir un objet, puis n requêtes pour obtenir les n objets liés à cet objet d'origine, vous pouvez modifier ce morceau de code pour utiliser le chargement impatient pour ne toucher que base de données une fois au lieu de N + 1 fois (le problème N + 1 est un inconvénient bien connu d'utiliser une chargement paresseux).
Mais si vous commencez à utiliser LAZYLOADER après que le projet soit devenu si énorme, il est tard pour changer de nombreuses choses. Je pense que la meilleure approche consiste à déterminer quelles données vous devez chercher à partir de la base de données dans une seule requête. Dans cette approche, vous pouvez ce dernier cache ces objectifs, mais vous ne pouvez pas mettre en cache ces objets qui ont la luisyloade.
@Meysam je suis d'accord avec vous, mais très souvent, vous construisez des prototypes ou tout simplement à la recherche d'un projet et à la recherche de performances de pointe à cette époque pourrait ne pas être l'utilisation la plus efficace de votre temps. Par exemple. Vous finissez par passer autant de temps à planifier le scénario de performance parfait pour un morceau de code pour découvrir par Sprint 3 que le projet adopte une direction différente due à la rétroaction des utilisateurs.
Si vous utilisez un service WebService entre le client et le serveur gérant l'accès à la base de données à l'aide de NHibernate, il peut être problématique à l'aide de la charge paresseuse car l'objet sera sérialisé et envoyé sur le site Web et l'utilisation ultérieure des "objets" plus bas dans l'objet La relation nécessite un nouveau voyage sur le serveur de base de données en utilisant des services Web supplémentaires. Dans un tel cas, il pourrait ne pas être trop bon en utilisant le chargement paresseux. Un mot de prudence, soyez prudent dans ce que vous allez chercher si vous tournez la chargement paresseux de sa manière facile de ne pas penser cela à travers et à traverser et finir par chercher presque toute la base de données ...
J'ai vu de nombreux problèmes de performance de la configuration de comportement de chargement incorrect dans Hibernate. La situation est tout à fait la même chose avec NHibernate, je pense. Ma recommandation consiste à toujours utiliser des relations paresseuses, puis à utiliser des statistiques désireuses de récupération dans votre requête - comme Fetch Joinages -. Cela garantit que vous ne chargez pas de nombreuses données et vous pouvez éviter de nombreuses requêtes SQL.
Il est facile de faire une relegence paresseuse désireuse d'une requête. Il est presque impossible l'inverse.