La connexion à la base de données sera-t-elle fermée si nous cédons la ligne du lecteur de données et ne lisons pas tous les enregistrements?

Tout en comprenant la façon dont les yieldœuvres de mots clés, je suis tombé sur link1 et lien2 sur StackOverflow qui préconise l'utilisation de yield returntout itérer sur le DataReader et il convient à mes besoins aussi bien. Mais cela me fait me demander ce qui se passe, si j'utilise yield returncomme indiqué ci-dessous et si je n'itère pas à travers DataReader entier, la connexion DB restera-t-elle ouverte pour toujours?

IEnumerable<IDataRecord> GetRecords()
{
    SqlConnection myConnection = new SqlConnection(@"...");
    SqlCommand myCommand = new SqlCommand(@"...", myConnection);
    myCommand.CommandType = System.Data.CommandType.Text;
    myConnection.Open();
    myReader = myCommand.ExecuteReader(CommandBehavior.CloseConnection);
    try
       {               
          while (myReader.Read())
          {
            yield return myReader;          
          }
        }
    finally
        {
            myReader.Close();
        }
}


void AnotherMethod()
{
    foreach(var rec in GetRecords())
    {
       i++;
       System.Console.WriteLine(rec.GetString(1));
       if (i == 5)
         break;
  }
}

J'ai essayé le même exemple dans un exemple d'application console et j'ai remarqué lors du débogage que le bloc finalement de GetRecords()n'était pas exécuté. Comment puis-je assurer la fermeture de DB Connection? Existe-t-il un meilleur moyen que d'utiliser un yieldmot-clé? J'essaie de concevoir une classe personnalisée qui sera responsable de l'exécution de certains SQL et procédures stockées sur DB et retournera le résultat. Mais je ne veux pas retourner le DataReader à l'appelant. Je veux également m'assurer que la connexion sera fermée dans tous les scénarios.

Modifier la réponse à la réponse de Ben car il est incorrect de s'attendre à ce que les appelants utilisent correctement la méthode et en ce qui concerne la connexion DB, cela coûtera plus cher si la méthode est appelée plusieurs fois sans raison.

Merci Jakob et Ben pour l'explication détaillée.

Oui, vous serez confronté au problème que vous décrivez: jusqu'à ce que vous ayez fini d'itérer le résultat, vous garderez la connexion ouverte. Il y a deux approches générales auxquelles je peux penser pour traiter ceci:

Poussez, ne tirez pas

Actuellement, vous retournez une IEnumerable<IDataRecord>structure de données à partir de laquelle vous pouvez extraire. Au lieu de cela, vous pouvez changer de méthode pour diffuser ses résultats. Le plus simple serait de passer dans un Action<IDataRecord>qui est appelé à chaque itération:

void GetRecords(Action<IDataRecord> callback)
{
    // ...
      while (myReader.Read())
      {
        callback(myReader);
      }
}

Notez que étant donné que vous avez affaire à une collection d'éléments, IObservable/ IObserverpeut être une structure de données légèrement plus appropriée, mais à moins que vous n'en ayez besoin, un simple Actionest beaucoup plus simple.

Évaluer avec enthousiasme

Une alternative consiste simplement à s'assurer que l'itération se termine entièrement avant de revenir.

Vous pouvez normalement le faire en mettant simplement les résultats dans une liste, puis en les renvoyant, mais dans ce cas, il y a la complication supplémentaire de chaque élément étant la même référence pour le lecteur. Vous avez donc besoin de quelque chose pour extraire le résultat dont vous avez besoin du lecteur:

IEnumerable<T> GetRecords<T>(Func<IDataRecord,T> extractor)
{
    // ...
     var result = new List<T>();
     try
     {
       while (myReader.Read())
       {
         result.Add(extractor(myReader));         
       }
     }
     finally
     {
         myReader.Close();
     }
     return result;
}

Votre finallybloc s'exécutera toujours.

Lorsque vous utilisez yield returnle compilateur, une nouvelle classe imbriquée est créée pour implémenter une machine à états.

Cette classe contiendra tout le code des finallyblocs en tant que méthodes distinctes. Il gardera une trace des finallyblocs qui doivent être exécutés en fonction de l'état. Tous les finallyblocs nécessaires seront exécutés dans la Disposeméthode.

Selon les spécifications du langage C #, foreach (V v in x) embedded-statementest étendu à

{
    E e = ((C)(x)).GetEnumerator();
    try
    {
        while (e.MoveNext())
        {
            V v = (V)(T)e.Current;
            embedded - statement
        }
    }
    finally {
        … // Dispose e
    }
}

ainsi l'énumérateur sera supprimé même si vous quittez la boucle avec breakou return.

Pour obtenir plus d'informations sur la mise en œuvre de l'itérateur, vous pouvez lire cet article de Jon Skeet

Éditer

Le problème avec une telle approche est que vous comptez sur les clients de votre classe pour utiliser correctement la méthode. Ils pourraient par exemple obtenir directement l'énumérateur et le parcourir en whileboucle sans le supprimer.

Vous devriez considérer l'une des solutions suggérées par @BenAaronson.

Quel que soit le yieldcomportement spécifique , votre code contient des chemins d'exécution qui ne disposeront pas correctement de vos ressources. Et si votre deuxième ligne lève une exception ou votre troisième? Ou même votre quatrième? Vous aurez besoin d'une chaîne try / finally très complexe, ou vous pouvez utiliser des usingblocs.

IEnumerable<IDataRecord> GetRecords()
{
    using(var connection = new SqlConnection(@"..."))
    {
        connection.Open();

        using(var command = new SqlCommand(@"...", connection);
        {
            using(var reader = command.ExecuteReader())
            {
               while(reader.Read())
               {
                   // your code here.
                   yield return reader;
               }
            }
        }
    }
}

Les gens ont remarqué que ce n'est pas intuitif, que les personnes qui appellent votre méthode peuvent ne pas savoir qu'énumérer le résultat deux fois appellera la méthode deux fois. Eh bien, bonne chance. C'est ainsi que la langue fonctionne. C'est le signal qui IEnumerable<T>envoie. Il y a une raison pour laquelle cela ne revient pas List<T>ou T[]. Les gens qui ne le savent pas doivent être éduqués, pas contournés.

Visual Studio possède une fonctionnalité appelée analyse de code statique. Vous pouvez l'utiliser pour savoir si vous avez correctement supprimé les ressources.

Ce que vous avez fait semble mal, mais fonctionnera bien.

Vous devez utiliser un IEnumerator <> , car il hérite également d' IDisposable .

Mais comme vous utilisez un foreach, le compilateur utilise toujours un IDisposable pour générer un IEnumerator <> pour le foreach.

en fait, le foreach implique beaucoup de choses en interne.

Vérifiez /programming/13459447/do-i-need-to-consider-disposing-of-any-ienumerablet-i-use