J'ai codé avec des blocs "en utilisant", mais je me demande si je peux retourner une iquérissable à partir de ce qui suit sans que l'objet soit disposé avant d'y accéder.
public IQueryable<Contact> GetContacts(string clientID)
{
using (dbDataContext db = new dbDataContext())
{
var contacts = from _contacts in db.Contacts
where _contacts.ClientID == clientID
orderby _contacts.LastName ascending
select _contacts;
return contacts;
}
}
4 Réponses :
Si vous ne vous attendez pas à composer davantage les données (sur le serveur DB), alors: bien que dans ce cas, je préfère retourner Si vous DO Attendez-vous à le composer, alors vous devez transmettre le contexte de données (ou, si possible, un ienumerable < Contact> ou ilist en amont IQuiseryable
@KIkLemonkey - C'est le type concret qui compte le plus là-bas, mais un avantage évident de ilist .Count etc (et un indexeur), rendant l'accès plus pratique. Mais quel que soit l'exemple ilist ienumerable ilist
Vous pouvez faire quelque chose comme ça
Cela ne vous aidera pas - l'exécution différée de requêtes LINQ signifie que le contexte de la DB est toujours disposé longtemps avant que getenumerator () est appelé la requête sous-jacente. Donc aucun forke.
Pouvez-vous faire l'objet de contexte une instance de membre de votre classe? Si vous pouvez également différer l'appel à exécuter la requête jusqu'à ce que vous touchiez l'énumérateur sous-jacent à l'instance iquérissable que vous retournez. Cela dépend de ce que vous voulez faire. Avez-vous besoin de retourner iquéry de cette méthode ou pouvez-vous faire avec iEnumerable?
Je pense que je vais aller avec l'iEnumerable, si j'utilise la méthode d'instance membre, je peux courir dans le même problème si ma classe est utilisée comme un bloc "en utilisant", et je veux accéder aux données retournées en dehors de cela. Merci pour la suggestion.
L'instance d'objet de contact dans un ensemble de résultats iquérissable conservera la référence de DataContext utilisé dans l'utilisation du bloc et fonctionnera dans le code du client comme prévu. Vous serez en mesure d'effectuer des opérations SQL différées sur l'instance iquéreuse résultante et de faire d'autres opérations iquérissables normalement.
Quand j'essaie, je reçois "DataContext accessible après le dispositif".
Notez qu'il n'est pas vraiment nécessaire d'éliminer explicitement le DataContext. bonne question alors quand même.
@farrofawhackplanet - er, oui c'est. Tout objet jetable doit être supposé que nécessite une élimination et doit être traité de manière appropriée, imo. Il peut contenir une connexion ouverte, par exemple ...
@MARC: Je vais juste faire ce que j'ai lu sur plusieurs blogs et aussi à peu près tous les exemples de Scotgu et de l'équipe Linq. La position officielle de Microsoft, autant que je puisse nous rassembler, c'est que vous pouvez disposer si cela vous fait sentir mieux, mais ce n'est vraiment pas nécessaire. Voir LEEDUMOND.COM/BLOG/ABOUT-DISPOSING-TRE-DATACONTEXT comme Un exemple de discussion de l'élimination et du problème d'exécution différé décrit dans cette question.
Scott Guthrie: "L'objet DataContext n'ouvre aucune connexion à la base de données - vous n'avez donc pas besoin de le disposer de nouvelles connexions du pool de connexion uniquement lorsqu'elle a besoin d'eux, puis les renvoie dès que cela se fait. » Vous ne pouvez pas vraiment l'obtenir sur une autorité supérieure à celle.
Pour quiconque cherche, voici un lien mis à jour pour l'article @fearofawhackplanet Publié: web.archive.org/web/20130702164240/http://leeduumond.com/blog / ...