Сейчас переводим проект, в котором используются датасеты (не типизированные), на .Net 3.5 И встал вопрос о том имеет ли смысл замена вызовов DataTable.Select запросами LINQ? Какие преимущества это может дать, и как подобная замена отразится на производительности?
Производительность LINQ To DataSet
3
Новые ответы
2
Linq To DataSet дает одно серьезное преимущество — возможность писать запросы не в виде строки, а в виде кода на C#/VB. Это означает, что ошибки запроса будут найдены во время компиляции, а не во время выполнения. Кроме того работает автодополнение среды и статическая типизация.
Linq To Sql дает только удобный способ доступа к уже загруженному DataSet. При этом сами операции с данными выполняются при помощи ADO.NET. Если основное проседание производительности происходит на уровне базы данных (фактически уровень ADO.NET), то хочется верить, что применение linq to dataset никак не скажется на производительности (или скажется незначительно).
Если отойти от темы linq, то следует заметить, что применение DataSet для доступа к данным в серьезном приложении не совсем оправдано. DataSet`ы не дают возможности создать богатую предметную область с наследованием, полиморфизмом и прочими фишками. По сути DataSet — это прямое отображение таблицы базы данных. Но не решает (а скорее усугубляет) проблем несоответствия реляционной и объектной парадигмы.
1
На самом деле я тестировал производительность запросов к DataTable и могу сказать, что Linq показал себя очень плохо... Если посмотреть через Reflector, то можно увидеть, что расширение LinqToDataSet всего лишь добавляет extension method AsEnumerable() к DataTable, для того чтобы задействовать стандартную инфраструктуру LinqToObjects.
Интересные результаты. А что если использовать ToQueryable() вместо AsEnumerable():
DataTable dt = GetTreeTable().ToQueryable();
t.Started("Выбираем все записи по первичному ключу запросом LINQ");
for (int i = 0; i < Iterations; i++) {
(from row in dt
where row.Field(0) == Rnd.Next(0, Iterations - 1)
select row).ToArray();
}
Тогда запросы будут строиться через механизмы DataSet, без преобразования к enumerable.
Я тоже так подумал, однако увы, во первых к DataTable не добавляется метод ToQueryable, а во вторых даже если обходным путем привести его к IQueryable то на результат это, к сожалению, не влияет...
Похоже так и есть. Метод ToQueryable был исключен из релиза linq to dataset (хотя был в preview). Я почему-то думал, что операции linq типа select должны делегироваться самому dataset`у, а не выполняться над коллекцией строк. На самом деле, видимо, происходит наоборот — таблица данных переводится в Enumerable, и все действия производятся на нем. А это не есть гуд.
При таком раскладе вообще не вижу смысла использовать linq to dataset. Разве только если заранее известно, что DataSet не хранит большле количество строк.
Вот-вот и я о том же...
На самом деле если стоит выбор между запросом в виде строки и запросом в виде C# кода, но почти в тысячу раз медленнее, то я предпочту производительность остальным преимуществам Linq запроса...
В Linq запросах к DataTable средства ADO.NET не задействуются... т.е. через ADO.NET мы можем только загрузить данные в DataSet, а при Linq запросах к загруженному датасету основные операции по выборке данных сводятся уже к простому перебору строк, что меня очень сильно удивило..
К сожалению в нашем проекте без датасета никак... поскольку весь UI и бизнес-логика находится в БД в виде метаданных