Je me pose des questions sur l'état de la connexion et de l'impact sur les performances du code par "rendement" lors de l'itération sur les données objet de lecteur

Voici mon exemple de code que j'utilise pour récupérer des données de la base de données:
sur la couche DAO:

public IEnumerable<IDataRecord> GetDATA(ICommonSearchCriteriaDto commonSearchCriteriaDto)
{
    using(DbContext)
    {
        DbDataReader reader = DbContext.GetReader("ABC_PACKAGE.GET_DATA", oracleParams.ToArray(), CommandType.StoredProcedure);
        while (reader.Read())
        {
            yield return reader;
        }
    }
}

Sur BO couche, je suis l'appel de la méthode ci-dessus comme:

List<IGridDataDto> GridDataDtos = MapMultiple(_costDriversGraphDao.GetGraphData(commonSearchCriteriaDto)).ToList();

sur mappeur couche MapMultiple méthode est définie comme:

public IGridDataDto MapSingle(IDataRecord dataRecord)
{
    return new GridDataDto
    {
        Code = Convert.ToString(dataRecord["Code"]),
        Name = Convert.ToString(dataRecord["Name"]),
        Type = Convert.ToString(dataRecord["Type"])     
    };
}
public IEnumerable<IGridDataDto> MapMultiple(IEnumerable<IDataRecord> dataRecords)
{
    return dataRecords.Select(MapSingle);
}

Le code ci-dessus fonctionne bien, mais je me pose des questions sur deux préoccupations avec le code ci-dessus.

Combien de temps les données du lecteur de connexion sera ouvert?
Quand je considère le code de facteur de performance seulement, Est-ce une bonne idée d'utiliser les "taux de retour" au lieu d'ajout d'enregistrement dans une liste et le retour de l'ensemble de la liste?

OriginalL'auteur Sanjeev Rai | 2013-03-13

c#datareader linq using yield-return

14
1. votre code n'affiche pas lorsque vous ouvrez/fermez la connexion; mais la lecteur ici uniquement être ouverts pendant que vous êtes en itérant les données. Exécution différée, etc. Le seul bit de votre code qui fait cela est la .ToList(), donc ça va être bien. Dans le cas plus général, oui: le lecteur sera ouverte pour la quantité de temps que vous prenez à le parcourir; si vous faites un .ToList() qui sera minime; si vous faites un foreach et (pour chaque élément) externe de la requête http et attendre 20 secondes, alors oui il sera ouvert plus longtemps.
2. Les deux ont leurs usages; la non-buffered approche est idéal pour les grands résultats que vous voulez traiter comme un ruisseau, sans jamais avoir à les charger en une seule liste en mémoire (ou même qu'ils les ont tous en mémoire à la fois); retourner une liste continue de la fermeture de la connexion rapidement, et il est facile d'éviter accidentellement à l'aide de la connexion alors qu'il a déjà une ouvrir lecteur, mais n'est pas l'idéal pour de grands résultats
Si vous retourne un itérateur bloc, l'appelant peut décider de ce qui est sain d'esprit; si vous retournez toujours une liste, ils n'ont pas beaucoup d'option. Un troisième moyen (ce que nous faisons dans dapper) est de faire le choix le leur; nous avons une option de bool paramètre dont la valeur par défaut de "retourner une liste", mais dont l'appelant peut changer pour indiquer "retour d'un itérateur bloc"; en gros:
```
bool buffered = true
```
dans les paramètres, et:
```
var data = QueryInternal<T>(...blah...);
return buffered ? data.ToList() : data;
```
dans la mise en œuvre. Dans la plupart des cas, le retour d'une liste est parfaitement raisonnable et évite beaucoup de problèmes, c'est pourquoi nous faire défaut.

merci pour la rapidité de votre réponse et de l'aide!

OriginalL'auteur Marc Gravell
4

Combien de temps les données du lecteur de connexion sera ouvert?

La connexion reste ouverte jusqu'à ce que le reader est rejetée, ce qui signifie qu'il serait ouvert jusqu'à l'itération est terminée.

Quand je considère le code de facteur de performance seulement, Est-ce une bonne idée d'utiliser yield return au lieu d'ajouter des enregistrement dans une liste et le retour de l'ensemble de la liste?

Cela dépend de plusieurs facteurs:
- Si vous ne prévoyez pas de récupérer l'intégralité de la suite, yield return vous aidera à économiser sur la quantité de données transférées sur le réseau
- Si vous ne voulez pas convertir des données renvoyées à des objets, ou si plusieurs lignes sont utilisées pour créer un objet unique, yield return vous aidera à enregistrer sur la mémoire utilisée lors de l'utilisation de pointe point de votre programme
- Si vous envisagez de parcourir les enture ensemble de résultats sur une courte période de temps, il n'y aura pas de performance des sanctions pour l'utilisation yield return. Si l'itération va durer une quantité importante de temps sur plusieurs threads simultanés, le nombre de curseurs ouverts sur le SGBDR côté peut devenir dépassés.
OriginalL'auteur dasblinkenlight
0

Cette réponse ignore les défauts dans la mise en œuvre et couvre l'idée générale.

Il est nécessaire de trouver un compromis - il est impossible de dire si c'est une bonne idée, sans en connaître les contraintes de votre système - qu'est-ce que la quantité de données que vous prévoyez d'obtenir, de la consommation de mémoire vous sont disposés à accepter la charge prévue sur la base de données, etc

OriginalL'auteur Zdeslav Vojkovic

Vous devez vous connecter pour publier un commentaire.