Обзор классов ADO.NET 2.0

Tsql теория > Обзор классов ADO.NET 2.0
26.02.2013 15:13:56



Статья:

 Обзор классов ADO.NET 2.0

Тип класса

Описание

Connection

Создает физическое соединение между СУБД и объектом DataAdapter, DataReader ИЛИ factory

ProviderFactory Новый класс AD0.NET 2.0. Каждый поставщик .NET реализует класс

ProviderFactory, который управляется из общего базового класса DBProviderFactory. Класс factory содержит методы создания специфичных для поставщика компонентов AD0.NET. Идея, заложенная в этом классе, позволяет разработчику написать обобщенный программный код, который использует поставщика, определяемого в ходе выполнения программы. Возможные поставщики, которые могут использоваться, хранятся в файле machine. conf ig

Command

Определяет действие, выполняемое в СУБД, например вставку, обновление или удаление строки. Класс DataAdapter содержит объекты команд, необходимых для выполнения запросов к базе данных, а также удаления, вставки и редактирования ее записей

Parameter

Параметр команды

Error

Информация об ошибке или предупреждении, возвращенном из базы данных.

В SQL Server эта информация содержит номер и текст ошибки, а также ее частоту

Exception

Исключение приложения, генерируемое, когда AD0.NET 2.0 встречает ошибку. Класс Error создается классом Exception. Класс Exception используется в AD0.NET 2.0 для обработки ошибок в выражениях try... catch

DataAdapter

Преобразует данные из источника данных поставщика в находящийся в памяти объект DataSet ИЛИ DataReader. Класс DataAdapter выполняет все запросы, преобразования данных из одного формата в другой, а также отображение таблиц. Один объект DataAdapter может поддерживать одно отношение базы данных. В результате коллекция может иметь любой уровень сложности. DataAdapter также отвечает за отправку запросов на новые подключения и закрытие подключений после получения данных

DataReader

Обслуживает соединение с базой данных в реальном времени. Однако этот объект обеспечивает работу только механизма чтения данных. К тому же курсор DataReader работает только в прямом направлении. Этот объект обычно используют для быстрого извлечения данных из локальной таблицы, когда не существует потребности в обновлении базы данных. Объект DataReader блокирует последующие объекты DataAdapter и ассоциированные с ними объекты Connection. Исходя из этого, не забывайте закрывать объект DataReader, как только потребность в нем отпала

DataSet

Содержит локальную копию данных, извлеченных одним или несколькими объектами DataAdapter. Объект DataSet использует локальную копию данных, так что подключение к базе данных не обслуживается в реальном времени. Пользователь может внести все изменения в локальную копию, а затем приложение затребует обновление. (Обновления могут выполняться в пакетном режиме или по одной записи за проход.) Объект DataSet поддерживает информацию как об исходном, так и о текущем состоянии каждой модифицированной строки. Если исходная строка данных соответствует находящейся в базе данных, то объект DataAdapter выполняет затребованное обновление; в противном случае DataAdapter возвращает ошибку, которую приложение должно обработать. Наборы данных DataSet в ADO.NET 2.0 могут быть типизированными и нетипизированными. Объекты DataSet определяются в пространстве имен System.Data, они не специфичны для конкретного поставщика. С поставщиком ассоциированы только классы DataAdapter.

Тип класса

Описание

Transaction

Это новый класс AD0.NET 2.0. Объект транзакции AD0.NET по умолчанию является обычным контейнером, работающим с одним источником данных. Если код ADO затребует в транзакции другой источник данных, транзакция будет незаметно преобразована в распределенную или многоэтапную, не требуя от разработчика дополнительного программирования

Visual Studio 2005 предлагает разработчику класс TableAdapter — набор дан-Назаметку ных одной таблицы, который можно использовать в приложении, подобно объекту DataSet ADO.NET 2.0. Если работа выполняется с одной таблицей, то класс TableAdapter существенно легче программировать, чем используемые им компоненты ADO.NET 2.0. Класс TableAdapter не управляется из класса System.Data.DataSet, как все остальные наборы данных. Более того, класс TableAdapter даже не является составным компонентом среды .NET Framework. Он находится на уровне абстракции, поддерживаемом программой Visual Studio 2005. Все объекты TableAdapter наследуют из класса System. Component. Component Model. Это значит, что данные объекты полностью интегрированы с инструментами Visual Studio, такими как Data Grid. К тому же базовым классом для TableAdapter может служить любой из поставщиков .NET, оснащенный классом DataTable. Базовый класс задается при создании объекта TableAdapter. Класс TableAdapter защищает типы и содержит все свойства и методы, необходимые для подключения к источнику данных, извлечения информации из таблицы и обновления источника данных. Более подробную информацию о классе TableAdapter вы сможете найти на сайте MSDN в статье “TableAdapters in Visual Studio 2005”:

http://msdn.microsoft.com/library/default.asp?url=/library/ en-us/dnvs05/html/tableadapters.asp

Управляемые поставщики

В ADO.NET 2.0 содержится четыре управляемых поставщика.

¦ OracleClient. Поставщик от Microsoft для баз данных Oracle. Этот поставщик требует установки на компьютере клиента СУБД Oracle.

¦ OleDb. Связующий поставщик для использования поставщиков OLE DB в ADO.NET.

¦ SqlClient. Поставщик от Microsoft для SQL Servber 7.0 и более поздних версий. Точно так же как поставщик OLE DB напрямую связывает SQL Server и ADO, SQLClient использует закрытый протокол для прямого подключения к SQL Server из ADO.NET.

¦ SqlServerCe. Поставщик от Microsoft для СУБД SQL Server СЕ Mobile Edition.

Как уже говорилось ранее, поставщик OracleClient требует наличия установленного клиента СУБД Oracle. Поставщик OleDB .NET для обеспечения тех же функций полагается на компоненты MDAC. SqlClient и SqlServerCe содержатся в библиотеке SQL Native Client.

ADO.NET 1.1 содержит управляемый поставщик odbc. Пространство имен для На заметку этого поставщика в ADO.NET 2.0 больше не поддерживается. В то же время SQL Native Client содержит драйвер ODBC, что обеспечивает поддержку существующих приложений, использующих ODBC. Однако удаление пространства имен System.Data.ODBC из ADO.NET2.0 является сигналом завершения поддержки программного интерфейса ODBC API для доступа к данным.

Несмотря на то что объектные модели ADO.NET 1.x использовали общую архитектуру MDAC, в них не существовало единого объекта, обеспечивающего выполнение команд, чтение данных и поддерживающего адаптер данных. В них существовали разные объекты, выполняющие данные задачи, специфичные для классов поставщиков, которые находились в разных библиотеках. Исходя из этого, разработчику приходилось выбирать пространство имен, подходящее для конкретного приложения. Выбранное пространство имен должно было быть согласовано с конкретным поставщиком.

В контексте работы с SQL Server это подразумевало использование объектов, которые компания Microsoft оптимизировала для работы с SQL Server, в том числе SqlConnection, SqlCommand. SqlDataReader и SqlDataAdapter.

Эти специфичные для поставщика классы продолжают поддерживаться. Когда источником данных является SQL Server, естественно, предпочтительнее использовать классы, оптимизированные для данного поставщика. В этом случае можно ожидать лучшей производительности. К тому же в ADO.NET существует альтернативный общий базовый класс, который можно использовать как вариант в новых проектах. В среде, которая должна поддерживать множество источников данных, использование общего класса может потребовать меньшего объема программирования, чем дублирование одной и той же логики для каждого из поставщиков. В то же время высока вероятность того, что программирование с использованием общего базового класса потребует дополнительной настройки под конкретного поставщика.

В табл. 30.4 представлены перекрестные ссылки классов System.Data. Common и классов, специфичных для поставщиков классов, доступных для каждого из типов, перечисленных в табл. 30.2.

При работе в ADO.NET 1.1 с источниками данных других СУБД разработчику На заметку необходимо использовать отдельное, но параллельное множество классов поставщиков ADO.NET для каждого из поставщиков. При работе со средой .NET Framework 1.1 это относится к классам пространств имен System.Data.OleDb, System.Data.Odbc и System.Data.OracleClient. Разработчики также могут создавать и дополнительных поставщиков, а сторонние источники данных могут сделать доступными пространства имен своих поставщиков. Те же интерфейсы, которые были использованы компанией Microsoft для создания включаемых классов поставщиков, могут быть использованы и для создания дополнительных поставщиков.

Таблица 30.4. Ссылки на классы из пространств имен ADO.NET 2.0

Тип класса (из табл. 30.3)

System.

Data.Common

System.Data. SQLCIient

System.Data. OracleClient

System.Data. OleDb

Connection

DbConnection

SqlConnection

OracleConnection

OleConnection

ProviderFactory

DbProviderFactory

SqlClientFactory

OracleClientFactory

OleDbFactory

Command

DbCoirimand

DqlCommand

OracleCommand

OleCommand

Parameter

DbParameter

SqlParameter

OracleParameter

OleParameter

Error

Отсутствует

SqlError

Отсутствует

OleError

Exception

DbException

SqlException

OracleException

OleException

DataAdapter

DbDataAdapter

SqlDataAdapter

OracleDataAdapter

OleDataAdapter

DataReader

DbDataReader

SqlDataReader

Orас1eDataReader

OleDataReader

Transaction

DbTransaction

SqlTransact ion

OracleTransaction

OleTransaction

В ADO.NET 2.0 пространство имен System. Data. Common представило базовый класс для создания независимого от поставщика программного кода (часто его называют обобщенным), использующего общий базовый класс, совместно используемый всеми поставщиками. В этой модели поставщик определяется, и к нему осуществляется доступ с помощью класса DbProviderFactory. Компонентами данного поставщика являются DbConnection, DbCommand, DbDataReader и DbDataAdapter. Независимая от поставщика модель позволяет определить в файле конфигурации приложения, реестре или другой структуре не только строку подключения, но и самого поставщика, а также принимать эти данные от самого пользователя в момент инициализации класса подключения. Данная модель получила название фабричной благодаря своей способности автоматически создавать экземпляры классов, специфичных для конкретных поставщиков. Создаваемые таким образом классы являются наследниками классов соответствующих пространств имен (SqlClient, OracleClient или OleClient). С точки зрения программиста, результатом такого подхода является упрощение кода и его инвариантность.

Во многих ситуациях можно ожидать определенных выгод от использования пространства имен System.Data. Common. Приложения, которые должны быть способны запускаться на многих платформах баз данных, являются первыми кандидатами на обобщение поставщиков в ADO.NET. Однако на практике каждый конкретный поставщик требует наличия расширений базовой модели. Базовый класс может оказаться не в полной мере пригодным для ис-аользования некоторыми поставщиками .NET без наличия в программном коде ссылок на специфичные для данного поставщика классы. Как результат, программирование с использованием обобщенных классов может оказаться более трудоемким, чем использование специфичных для поставщиков пространств имен. Несомненно, в следующих версиях ADO.NET практичность обобщенных базовых классов будет повышаться. Возможно даже, что специфичные для поставщиков классы, управляемые из обобщенного, в будущем даже попадут в немилость. В настоящее же время, пожалуй, всем программистам (разумеется, кроме самых безрассудных) имеет смысл подходить к обобщенной модели с изрядной долей осторожности.

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

¦ Методика доступа к объектам. Неуправляемый поставщик для доступа к необходимым объектам будет использовать идентификатор COM proglD. При работе с управляемым поставщиком приложение полностью полагается на класс Command. Этот класс также имеет доступ к идентификатору COM proglD, но он скрывает от разработчика детали этого доступа, что ускоряет процесс создания приложений и защищает его от ошибок. Этот класс также позволяет рационализировать доступ к данным клиента SQL и делает возможным создание такого кода ADO.NET, который будет иметь один и тот же вид, независимо от того, использует ли доступ идентификатор COM prog ID или нет.

¦ Обработка результирующих данных. Неуправляемый поставщик для представления данных в приложении полагается на объекты Parameter объекта Command, а также на объекты Recordset и Stream модели ADO. Управляемый эквивалент использует классы Parameter, DataSet, DataTable и DataReader, а также методы Ехе-cuteReader, ExecutePageReader, ExecuteNonQuery и ExecuteScalar объекта Command и потоки XML. Неуправляемый интерфейс СОМ всегда будет испытывать перегрузки от преобразования типов данных SQL в типы данных СОМ. Управляемые поставщики в этом отношении имеют существенное преимущество, так как используют транспортные потоки, основанные на XML.

¦ Обновление данных. Так как в неуправляемой среде используется постоянно поддерживаемое подключение, ресурсы также находятся в постоянном использовании. В результате этого пользователь всегда должен иметь подключение к базе данных, а разработчику приходится тратить массу времени на создание команд вручную. Управляемая среда использует подключения, только если требуется транспортировка данных. Вследствие этого использование ресурсов становится более эффективным, и пользователю нет необходимости поддерживать постоянное подключение. Как будет показано ниже в этой главе, управляемая среда предоставляет и другие средства автоматизации, включая метод CommandBuilder.

¦ Формат передачи данных. Неуправляемая среда использует передачу двоичных данных. Управляемые поставщики данных при передаче данных в ADO.NET 1.x полагаются исключительно на формат XML. Распределенные приложения в ADO.NET 2.0 также могут при передаче использовать двоичную сериализацию, значительно выигрывая в объеме передаваемых данных по сравнению с XML, в тех случаях, когда удаленность применима в задаче. Удаленность обеспечивает повышенную производительность и интероперабельность в процессах взаимодействия приложений .NET. Если либо источник, либо приемник не является приложением .NET, стандартизованный метод передачи данных обеспечивает формат XML. Это требует гораздо меньшего объема программного кода и меньших затрат на поддержку, чем неуправляемые методы передачи данных.

Отличия между методами передачи данных неуправляемых и управляемых поставщиков требуют от программиста основательного исследования. Формат передачи данных XML. используемый управляемым поставщиком, больше подходит для архитектуры SOA и Интернета, так как позволяет передавать данные через брандмауэры, которые обычно блокируют двоичные потоки. В то же время XML является более затратным методом передачи данных и не столь безопасен. В прошлом было привлекательно использовать ADO для потребностей локальных баз данных и ADO.NET для распределенных приложений, так как формат XML явно проигрывает в размерах и производительности. Также в этом имела значение обманчивая повышенная защищенность двоичных данных по сравнению с байтами ASCII при передаче по частной сети. Двоичная сериализация ADO.NET 2.0 обладает преимуществами производительности при направлении данных во внешние потоки, таким образом ослабляя, часто ущербное, стремление одновременно поддерживать модели ADO и ADO.NET.