Главная » Microsoft SQL Server, Базы данных » Обзор AD0.NET – ЧАСТЬ 6

0

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 практичность обобщенных базовых классов будет повышаться. Возможно даже, что специфичные для поставщиков классы, управляемые из обобщенного, в будущем даже попадут в немилость. В настоящее же время, пожалуй, всем программистам (разумеется, кроме самых безрассудных) имеет смысл подходить к обобщенной модели с изрядной долей осторожности.

Более подробную информацию об обобщенных базовых классах и DBProvider Factory вы можете получить из статьи Боба Бошемена (Bob Beauchemin) “Generic Coding with the ADO.NET 2.0 Base Classes and Factories” и статьи доктора Шахрама Хосрави (Shahram Khosravi) “Writing Generic Data Access Code in ASP.NET 2.0 and ADO.NET 2.0”, опубликованных на сайте MSDN по адресам:

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

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

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

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

?               Обработка результирующих данных. Неуправляемый поставщик для представления данных в приложении полагается на объекты Parameter объекта Command, а также на объекты Recordset и Stream модели ADO. Управляемый эквивалент использует классы Parameter, DataSet, DataTable и DataReader, а также методы ExecuteReader, 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.

Источник: Нильсен, Пол. Microsoft SQL Server 2005. Библия пользователя. : Пер. с англ. — М. : ООО “И.Д. Вильямс”, 2008. — 1232 с. : ил. — Парал. тит. англ.

По теме:

  • Комментарии