Сильно типизированные наборы данных улучшают производительность?

Question

Там, где я работаю, мы наконец приходят к идее использования строго типизированных наборов данных для инкапсуляции некоторых наших запросов в sqlserver. Одной из идей, которую я рекламировал, является сила строго типизированных столбцов, в основном из-за того, что не нужно приводить какие-либо данные. Я ошибаюсь, полагая, что наборы данных со строгой типизацией улучшат производительность в следующей ситуации, когда потенциально могут быть тысячи строк?

старый способ:

using(DataTable dt = sql.ExecuteSomeQuery())
{
    foreach (DataRow dr in dt.Rows)
    {
        var something = (string)dr["something"];
        var somethingelse = (int)dr["somethingelse"];
    }
}

новый способ:

MyDataAdapter.Fill(MyDataset);
foreach (DataRow dr in MyDataset.MyDT.Rows)
{
    var something = dr.Something;
    var somethingelse = dr.SomethingElse;
}

Если свойства на самом деле просто выполняют кастинг за кулисами, я вижу, как не будет никакого ускорения вообще; возможно, это заняло бы еще больше времени, чем прежде, с учетом накладных расходов на вызов функции.

Существуют ли какие-либо другие сильные / слабые стороны в использовании наборов данных, о которых мы должны знать?

Спасибо!

Answer 1

Я не уверен, будут ли какие-либо улучшения производительности с использованием строго типизированных наборов данных, однако вы получаете дополнительную безопасность типов, а вместе с этим и ошибки компилятора, например, при неправильном вводе имени поля.

В журнале MSDN есть статья о них , в которой указывается строка:

Скорость доступа к типизированному DataSet сравнима с более быстрыми методами доступа к нетипизированному DataSet (поскольку типизированный DataSet - это просто слой над нетипизированным DataSet), а читаемость типизированного DataSet является лучшей

Кроме того, как указывал Стюарт Б., только Интеллект имеет смысл.

Answer 2

Если вы посмотрите на код, сгенерированный для типизированного набора данных, вы увидите, что под каждым типизированным вызовом находится вызов, выполненный со строковым индексированным именем. Таким образом, они действительно не дают никакого повышения производительности, только безопасность типов.

Тем не менее, у меня есть большой недостаток в обнуляемых полях в наборе типизированных данных. В частности, если вы обращаетесь к полю int, которое имеет значение null, оно выдает исключение. Сначала вы должны вызвать вызов IsMyfieldNull (), чтобы определить, является ли оно пустым, и избегать ссылки на него, если оно есть. Реальным решением для этого было бы использование пустых полей типа, поэтому вы не рискуете вызвать исключение только для прикосновения к полю. Этот недостаток в моем сознании почти сводит на нет преимущества набора текста.

Answer 3

Не забудьте Intellisense. Это вкусно.

Answer 4

Строго типизированные DataSet - это просто строго типизированная оболочка для того же нетипизированного DataSet, который вы в противном случае использовали бы. Предполагая, что вы будете использовать нетипизированный DataSet разумным и эффективным способом, строго типизированный DataSet не будет быстрее (с точки зрения выполнения).

Answer 5

Да, есть преимущество от использования строго типизированных наборов данных - и это от поиска столбцов. Поиск столбца по имени медленнее, чем поиск столбца по типу. Код, сгенерированный для строго типизированных наборов данных, просматривает столбцы по типу, поэтому вы получаете некоторое повышение производительности.

Answer 6

Технически говоря, должен быть небольшой удар по производительности от создания строго типизированного набора данных. Хотя создание строго типизированного набора данных приносит много преимуществ. С точки зрения ремонтопригодность и программирование. Помимо Intellisense, если что-то изменится на вашем уровне доступа к данным, вам не придется искать что-либо вроде «столбца 1». Вам просто нужно изменить место, где вы фактически присваиваете значения объекту.

Это похоже на то, «стоит ли производительность падать». Это медленнее, но небольшая скорость стоит повышенного уровня производительности.