Est-ce que Lazy Loading est vraiment mauvais?

Question

J'entends beaucoup parler de problèmes de performance sur le chargement paresseux, peu importe si à NHibernate, Linq ....

Le problème est N + 1 sélections. Par exemple, je veux tous les messages et ses utilisateurs, à tous les utilisateurs de chargement paresseux, j'ai besoin d'un select pour les messages, plus N select pour chaque utilisateur.

Lazy Chargement:

1-select ....from post
N - approche select ....from user

Le "bon" est faire une jointure:

1-select .....from post inner join user on post.UserId = user.Id

Mais voir EF généré SQL, J'ai réalisé que beaucoup de données étaient gaspillées. Imaginez que tous les messages sont le même utilisateur. Inner Join amènera toutes les colonnes d'utilisateurs pour chaque ligne de publication.

En performance, quelle approche est la meilleure?

Answer 1

Le chargement paresseux n'est ni bon ni mauvais. Voir ce pour une explication plus longue:

When should one avoid using NHibernate's lazy-loading feature?

En chargement général, paresseux est un bon comportement par défaut pour un ORM, mais en tant qu'utilisateur ORM vous devez être conscient de quand remplacer les données par défaut et la charge vivement. Le profilage des performances de votre application est le meilleur moyen de prendre des décisions sur l'utilisation du chargement paresseux ou de ne pas l'utiliser. Méfiez-vous de dépenser trop d'efforts sur l'optimisation prématurée.

Answer 2

Il n'y a pas de mauvais et bon pour le chargement paresseux. Vous devez décider si vous préférez charger des ressources lors de l'exécution ou des temps de chargement des applications. Par exemple - Le temps réel utilise généralement un tampon pour éviter d'allouer des ressources à l'exécution. C'est le contraire du chargement paresseux et est bénéfique pour le logiciel en temps réel.

Le chargement paresseux est utile si vous avez une application qui dure longtemps et que vous ne voulez pas allouer de ressources au démarrage.

Answer 3

Le problème avec Lazy Loading est de savoir ce que c'est et quand il peut vous mordre. Vous devez savoir combien de déplacements potentiels pourraient être faits dans la base de données, et comment contourner cela. Je ne considère pas LL comme étant mauvais. Je dois juste être conscient des ramifications de celui-ci.

Answer 4

La plupart de mes applications impliquent une limite de service (service web, WCF, etc) et à ce moment le chargement paresseux à l'OR/M est inutile, et le chargement paresseux dans vos entités est très aimable. d'une mauvaise idée (les entités doivent maintenant connaître le service).

Answer 5

Ancien fil, mais la recherche l'a fait monter ainsi j'ajoute mes deux cents. En plus d'avoir à connaître les problèmes de performance potentiels, la question de l'accès aux champs après la mise à disposition d'un contexte de données m'empêche d'utiliser LL maintenant. Si vous renvoyez une instance d'une entité à partir d'une méthode dans laquelle un contexte de données a été créé et éliminé, et de quelle manière ils sont conçus pour être utilisés, l'accès à ces champs virtuels entraîne une exception. Les solutions à cela sont soit d'inclure les champs dans les requêtes (c'est-à-dire .Inclure), ne jamais retourner les classes d'entités de votre couche de données/service, ou garder les contextes de données en vie pour beaucoup plus longtemps. Y compris les champs est la meilleure option, et c'est aussi facile sans chargement paresseux activé.