J'ai vu beaucoup de projets qui ont des référentiels qui renvoient des instances de IQueryable
. Cela permet des filtres supplémentaires et le tri peut être effectué sur un IQueryable
autre code, ce qui se traduit par la génération de SQL différent. Je suis curieux de savoir d'où vient ce modèle et si c'est une bonne idée.
Ma plus grande préoccupation est qu’il IQueryable
s’agisse d’une promesse de consulter la base de données quelque temps plus tard, lorsqu’elle est énumérée. Cela signifie qu'une erreur serait renvoyée à l'extérieur du référentiel. Cela pourrait signifier qu'une exception Entity Framework est renvoyée dans une couche différente de l'application.
J'ai également rencontré des problèmes avec plusieurs ensembles de résultats actifs (MARS) dans le passé (en particulier lors de l'utilisation de transactions) et cette approche semble donner lieu à ce que cela se produise plus souvent.
J'ai toujours appelé AsEnumerable
ou ToArray
à la fin de chacune de mes expressions LINQ pour m'assurer que la base de données est touchée avant de quitter le code du référentiel.
Je me demande si le retour IQueryable
pourrait être utile en tant que bloc de construction d'une couche de données. J'ai vu du code assez extravagant avec un référentiel appelant un autre référentiel pour en créer un encore plus volumineux IQueryable
.
where
clause à un différé IQueryable
, il vous suffit d'envoyer ces données par câble, et non l'ensemble du résultat.