Таблица данных ADO.NET по сравнению со средством чтения данных

Когда я исследовал это раньше, я обнаружил, что разница в производительности между DataReader и DataTable была незначительной, за исключением, возможно, очень больших объемов данных. С тех пор я обычно использую DataTable, поскольку он более полнофункциональный, может работать без подключения и т. Д.

Я никогда не выпускал DataReader на волю (out ДАЛ). Только вопрос времени, когда вы оставите какие-то связи открытыми. Кроме того, я почти никогда не имею дело с таким большим объемом данных за один вызов, когда передача DataTable или DataSet представляет собой проблему.

Мы используем объектно-ориентированный язык, и DAL действительно может этим воспользоваться. В вашем проекте должна быть только одна строка кода, которая получает строку подключения. Только один объект, который действительно касается базы данных (вызывает ExecuteNonQuery, DA.Fill () и т. Д.)

Это также позволяет вам активно участвовать в регистрации исключений и т. Д., Потому что вы делаете это только один раз.Итак, в одном базовом классе DAL, который я использую для всего моего объекта DAL во всем моем проекте, у меня есть логика, что если DAL выдает исключение, он записывается в таблицу в моей базе данных. Это ведение журнала переключается на текстовый файл в случае сбоя регистрации базы данных.

So the code I see a lot looks like:
-   Start a try block
-   Make a SQLCommand
-   Get connection string.
-   Make Connection object
-   Open the connection
-   Get the data
-   Bind the data
-   Close the connection
-   Log error if exception

Поскольку я инкапсулирую все это, мой код для получения данных теперь выглядит так:

GridView1.DataSource = cProgram.DB.getMyData();

(или, что более вероятно, объект BAL находится между 2). БД - это обычный объект (не статический), но он создается только один раз для каждого приложения.

Пусть ваш слой данных возвращает объекты, а не таблицы данных или устройства чтения данных. Я бы предложил вам заполнять объекты с помощью считывателя данных.

Что я обычно делаю, так это открываю ридер с помощью CommandBehavior.CloseConnection. Затем я прохожу через считыватель и считываю данные в свою собственную объектную модель или список или что-либо еще в памяти вместе с данными, а затем закрываю считыватель. Это делает почти то же самое, что и таблица данных, но я просто ненавижу иметь дело с раздутыми и свободно типизированными структурами данных.

Если вы хотите полностью абстрагироваться от соединений и церемоний ADO.NET, DataReader - это небольшая проблема. Мне очень не нравится, когда мой инструмент данных имеет открытое соединение на свободе, надеясь, что DataReader будет утилизирован (если вы использовали опцию CommandBehavior.CloseConnection). Кроме того, при использовании большого количества DataReader'ов трудно объединять соединения, поскольку вы не можете ничего сделать с соединением, пока предыдущий DataReader не будет закрыт. Их нельзя легко передавать друг другу. Ваш Data-инструмент не является истинной абстракцией.

DataTables, с другой стороны, чрезвычайно гибкие и могут создавать очень эффективный и понятный код. Linq-To-DataTable - это замечательно. К счастью, DataTable на самом деле довольно эффективна. Для не огромных наборов результатов она почти так же быстра, как datareader. (Конечно, это зависит от того, что именно вы делаете). Все больше и больше я получаю DataTable из своего инструмента данных, а не из Readers. Это действительно упрощает жизнь. Я могу продолжать использовать одно и то же открытое соединение. В data-tool нет "состояния".

Код для получения DataReader очень прост. Поэтому, когда мне действительно нужен DataReader (не часто), я просто позволяю моему DAL передать мне мое соединение и сам получаю DataReader.