ADO.NET les données en tableau ou de lecteur de données

Oui, le lecteur de données est certainement le plus efficace - mais vous ne pas voulez garder une connexion ouverte pendant une longue période de temps!

• utiliser le DataReader pour lire vos données dans un objet entité; ouvrir la connexion, lire les données, fermer la connexion
• faire tout ce que vous devez faire avec votre entreprise objet
• de stocker les modifications, par exemple à l'aide d'un ad-hoc requête SQL, une procédure stockée, ou ce que vous voulez; de nouveau: ouvrir la connexion, écrire les changements, fermer la connexion

C'est probablement le plus efficace que vous pouvez obtenir - c'est un peu de travail, du code ennuyeux, et tout, mais c'est à peu près aussi vite qu'il peut l'être.

Si vous êtes plus intéressé dans la productivité des développeurs de vitesse brute, pourquoi ne pas utiliser un certain type d'un ORM pour faire tout cela ennuyeux, ennuyeux cartographie d'avant en arrière? Enregistre vous beaucoup de codage et de désordre de trucs pour maintenir la!

OriginalL'auteur marc_s

Laissez votre couche de données de retour objets, pas de tables de données ou de données lecteurs. Je vous suggère de remplir vos objets à l'aide d'un lecteur de données.

OriginalL'auteur Robert

Laissez-nous avoir une idiot de référence de vérifier à combien plus le DataReader (.Net version 4) est.
Je l'ai récupéré un enregistrement de la base de données (SQL Server 2000) et de lire tous ses domaines. J'ai répété ce processus de 1000 fois. DataReader a pris 17.3327585 secondes et DataTable a pris 18.37320156 et donc DataReader est ~1.04 secondes plus rapide que DataTable pour 1000 lit.

Donc, on pourrait obtenir un gain de performance de 0.00104 secondes si DataReader est préféré au cours de DataTable.

Regarder Est DataSet plus lent que DataReader en raison de...? ainsi

OriginalL'auteur bjan

Si vous voulez complètement abstraites, des connexions et de la cérémonie de ADO.NET le DataReader est un défi de taille. Je n'aime vraiment pas mon outil de données ayant une connexion ouverte sur le lâche, en espérant DataReader est éliminé (en supposant que vous avez utilisé l'option CommandBehavior.CloseConnection). Aussi, lors de l'utilisation de beaucoup de DataReaders, il est difficile de pool de connexions, puisque vous ne pouvez pas faire n'importe quoi avec la connexion jusqu'à ce que le précédent DataReader est fermé. Ils ne peuvent pas être transmis facilement. Vos Données-outil n'est pas un vrai abstraction.

DataTables d'autre part, sont extrêmement flexible et peut faire pour certains très efficace, un code clair. Linq-To-DataTable est grande. Heureusement, la DataTable est en fait assez efficace. Pour les non-énormes résultats, il est presque aussi rapide que le datareader. (cela dépend bien sur exactement ce que vous faites.) De plus en plus et je reçois des tables de données à partir de mes données-outil plutôt que de Lecteurs. Il rend la vie simple. Je peux continuer à utiliser la même connexion ouverte. Il n'y a pas un "état" dans les données de l'outil.

Le code pour l'obtention d'un DataReader est très simple. Alors, quand j'ai vraiment besoin d'un DataReader (pas souvent), je viens de laisser mon DAL-moi ma connexion et j'ai mes DataReader moi-même.

OriginalL'auteur Patrick Karcher

C'est le même que j'ai posté ici.

J'ai fait un peu de benchmarking moi-même avec des approches différentes:

public DataTable Read1(string query)
{
using (var cmd = conn.CreateCommand())
{
cmd.CommandText = query;
cmd.Connection.Open();
var table = new DataTable();
using (var r = cmd.ExecuteReader())
table.Load(r);
return table;
}
}
public DataTable Read2<S>(string query) where S : IDbDataAdapter, IDisposable, new()
{
using (var da = new S())
{
using (da.SelectCommand = conn.CreateCommand())
{
da.SelectCommand.CommandText = query;
da.SelectCommand.Connection.Open();
DataSet ds = new DataSet();
da.Fill(ds);
return ds.Tables[0];
}
}
}
public IEnumerable<S> Read3<S>(string query, Func<IDataRecord, S> selector)
{
using (var cmd = conn.CreateCommand())
{
cmd.CommandText = query;
cmd.Connection.Open();
using (var r = cmd.ExecuteReader())
while (r.Read())
yield return selector(r);
}
}
public S[] Read4<S>(string query, Func<IDataRecord, S> selector)
{
using (var cmd = conn.CreateCommand())
{
cmd.CommandText = query;
cmd.Connection.Open();
using (var r = cmd.ExecuteReader())
return ((DbDataReader)r).Cast<IDataRecord>().Select(selector).ToArray();
}
}
public List<S> Read5<S>(string query, Func<IDataRecord, S> selector)
{
using (var cmd = conn.CreateCommand())
{
cmd.CommandText = query;
cmd.Connection.Open(); 
using (var r = cmd.ExecuteReader())
{
var items = new List<S>();
while (r.Read())
items.Add(selector(r));
return items;
}
}
}

1 et 2 retours DataTable tandis que le reste fortement typé ensemble de résultats, de sorte que son exactement pas des pommes avec des pommes, mais j'ai tout le temps en conséquence.

Seulement l'essentiel:

Stopwatch sw = Stopwatch.StartNew();
for (int i = 0; i < 100; i++)
{
Read1(query); //~8900 - 9200ms
Read1(query).Rows.Cast<DataRow>().Select(selector).ToArray(); //~9000 - 9400ms
Read2<MySqlDataAdapter>(query); //~1750 - 2000ms
Read2<MySqlDataAdapter>(query).Rows.Cast<DataRow>().Select(selector).ToArray(); //~1850 - 2000ms
Read3(query, selector).ToArray(); //~1550 - 1750ms
Read4(query, selector); //~1550 - 1700ms
Read5(query, selector); //~1550 - 1650ms
}
sw.Stop();
MessageBox.Show(sw.Elapsed.TotalMilliseconds.ToString());

La requête a retourné environ 1200 lignes et 5 champs (run de 100 fois). En dehors de Read1 tous de bons résultats. De tous, je préfère Read3 qui renvoie des données paresseusement, comme indiqué. Ce qui est excellent pour la mémoire si vous avez seulement besoin de les énumérer. Pour avoir une copie de la collection dans la mémoire, vous êtes mieux avec Read4 ou Read5 comme vous s'il vous plaît.

OriginalL'auteur nawfal