2010-11-23 70 views
1

Je suis tombé sur ce post alors que je cherchais des choses pour améliorer les performances. Actuellement, dans mon application, nous retournons IList<> partout. Est-ce une bonne idée de changer tous ces retours à AsQueryable()?Dois-je toujours retourner IQueryable <> au lieu de IList <>?

Voici ce que j'ai trouvé -

  • AsQueryable() - Contexte doit être ouvert et vous ne pouvez pas contrôler la durée de vie du contexte de base de données il doivent être éliminées correctement. En outre, il est exécution différée (« filtrage plus rapide » par rapport aux listes)
  • IList<> - Cela devrait être préféré sur List<> car il fournit un barebone et la mise en œuvre légère.

De même quand devrait-on en préférer un autre? Je connais les bases, mais je suis désolé, je ne suis toujours pas clair quand et comment devrions-nous les utiliser correctement dans une application. Ce serait génial de le savoir car la prochaine fois j'essaierais de le garder à l'esprit avant de retourner quelque chose ... Merci beaucoup.

Répondre

2

Fondamentalement, vous devriez essayer de référencer le type le plus large dont vous avez besoin. Par exemple, si une variable est déclarée List<...>, vous définissez une contrainte pour le type des valeurs qui peuvent lui être affectées. Il peut arriver que vous ayez seulement besoin d'un accès séquentiel, donc il suffirait de déclarer la variable comme IEnumerable<...> à la place. Cela vous permettra d'affecter les valeurs des autres types à la variable, ainsi que les résultats des opérations LINQ.

Si vous voyez que votre variable doit être accessible par index, vous pouvez la déclarer à nouveau comme IList<...> et pas seulement List<...>, en lui affectant d'autres types d'implémentation IList<...>.

Pour les types de retour de fonction, cela dépend de vous. Si vous pensez qu'il est important que la fonction renvoie exactement List<...>, vous déclarez qu'elle doit renvoyer exactement List<...>. Si la seule chose importante est l'accès au résultat par index, peut-être vous n'avez pas besoin de vous contraindre à retourner exactement List<...>, vous pouvez déclarer le type de retour comme IList<...> (mais retourner réellement une instance de List<...> dans cette implémentation, et éventuellement de un autre type supportant IList<...> plus tard). Encore une fois, si vous voyez que la seule chose importante concernant la valeur de retour de votre fonction est qu'elle peut être énumérée (et l'accès par index n'est pas nécessaire), vous devez changer le type de retour de la fonction en IEnumerable<...>.

Maintenant, environ AsQueriable, encore une fois cela dépend de votre logique. Si vous pensez qu'une évaluation différée possible est une bonne chose dans votre cas, car cela peut vous aider à éviter les calculs inutiles, ou vous avez l'intention de l'utiliser dans le cadre d'une autre requête, vous l'utilisez. Si vous pensez que les résultats doivent être «matérialisés», c'est-à-dire, calculés à ce moment précis, il vaut mieux retourner un List<...>. Vous devrez notamment matérialiser votre résultat si le calcul effectué ultérieurement peut entraîner une liste différente!Avec la base de données, une bonne règle est d'utiliser AsQueriable pour les résultats intermédiaires à court terme, mais List pour les résultats «finaux» qui seront utilisés dans un temps plus long. Bien sûr, avoir une requête non-matérialisée qui traîne rend la fermeture de la base de données impossible (puisque au moment de l'évaluation réelle de la base de données devrait être encore ouverte).

0

si vous ne souhaitez pas faire d'autres requêtes sur SQL Server, vous devez retourner IList car elle produit en mémoire des données

0

Si vous êtes préoccupé par les performances, vous devez également essayer d'exécuter vos requêtes sur le moins de requêtes DB possible et mettre en cache les requêtes les plus utilisées. Il est très courant de réduire considérablement le temps de traitement des demandes en utilisant des approches par lots.

Quelle ORM utilisez-vous pour extraire des données de la base de données? Si vous utilisez NHibernate, consultez ce post sur la façon d'utiliser Future, Multi Criteria 1, Multi Criteria 2 et Multi Query.

Salutations.