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

0

Сохраняя традиции доступа к данным компании Microsoft, пакет ADO.NET 2.0 создан на основе существующих технологий доступа к данным. С выходом в свет SQL Server версии 1.1 в этих традициях проявились некоторые общие направления развития. Каждое следующее поколение продуктов делало подключения приложения к данным проще, чем в предыдущем, при этом расширяя список доступных средств и обеспечивая большую гибкость. Все эти улучшения всегда вели в сторону основных целей современного программирования— использования распределенной структуры вычислений, многоуровневой и клиент-серверной архитектуры, а также архитектуры, основанной на службах (SOA), в том числе на Web- службах. С каждым новым шагом технология доступа к данным стремилась устранить проблемы, выявленные у своих предшественников, в таких областях, как поддержка ссылочной целостности, производительности и надежности приложений.

В каждой новой версии SQL Server все старые технологии сохраняли свою силу, одновременно дополняясь новыми. Только в очень редких случаях доступ данных претерпевал революционные изменения. SQL Server 2005 в этом отношении не стал исключением. С выходом этой версии интерфейс библиотеки DB отошел в прошлое.

Библиотека DB больше не поддерживается в версии SQL Server 2005, а биб- Совет      лиотека MDAC (Microsoft Data Access Components) считается устаревшей. Ком

пания Microsoft больше не предлагает средства разработки приложений, использующих библиотеку DB. Если такое возможно, DB-приложения следует обновить. В то же время существует возможность продолжить использование старых приложений в SQL Server 2005. Для этого необходимо скопировать динамическую библиотеку ntwdblib.dll с носителя установки предыдущей версии SQL Server на клиентский компьютер. Этот файл нужно скопировать в каталог приложения, использующего библиотеку DB, или в папку, указанную в строке переменной среды %ратн%.

Исходная, или “классическая”, библиотека ADO уже устаревает и не поддерживается новым клиентом SQL Native Client. Для ссылок на этот новый интерфейс программирования в документации компания Microsoft использует аббревиатуру SQLNCLI. В то же время пользователи отдают предпочтение более краткой аббревиатуре SNAC.

Библиотека ADO поставляется со старыми библиотеками MDAC, к тому же у нее сохранилась возможность доступа к базам данных SQL Server 2005. Однако новые средства SQL Server 2005 больше не доступны для данной библиотеки, поэтому в новых приложениях лучше ее не использовать. Поэтому спланируйте, как лучше заменить или обновить приложения, использующие библиотеку ADO и лежащую в ее основе технологию COM (Component Object Model). В будущих версиях SQL Server не будет поддерживать ни ADO, ни СОМ.

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

Технология ADO принесла в платформу разработки приложений Windows невиданные ранее скорость и гибкость обращения к данным и манипулирования ими. Начиная с ADO и основанных на технологии СОМ интерфейсов OLE DB, разработчики получили возможность работы с гетерогенными источниками данных — от документов до баз данных — с помощью единой состоятельной методологии. Технология ADO абстрагировала мощные, но сложные компоненты СОМ и интерфейсы OLE DB в простую и дружественную объектную модель, позволяющую большому числу программистов и Web-разработчиков создавать качественные приложения.

ADO

Даже сегодня ADO остается технологией доступа к данным, основанной на компонентах СОМ. Очень важно осознавать, что компоненты Object Linking and Embedding (OLE DB) окружали нас с первых дней существования платформы Microsoft Windows. С тех пор многое изменилось. Самыми заметными событиями были публикация спецификации СОМ и совсем недавнее перемещение доступа к данным с уровня операционной системы на уровень общеязыковой среды выполнения CLR. В то же время многое осталось неизменным. Несмотря на стремительные изменения в мире баз данных, принятие сообществом разработчиков ранних версий OLE и СОМ продолжалось достаточно долго. Только после этого можно было достигнуть совершенства. Хотелось бы надеяться, что проникновение в массы технологии .NET будет не столь долгим, и на гребне волны она продержится гораздо дольше. Хотя компания Microsoft заверяет, что двоичный стандарт СОМ переживет следующие версии системы Windows, велика вероятность того, что он постепенно отойдет в небытие. Поступательное движение в сторону перемещения данных с помощью XML оставляет технологиям СОМ и ADO только шанс играть роли второго или третьего плана.

Характерным сигналом в этом отношении явилось то, что с выходом версии ADO.NET 2.0 компания Microsoft рекомендует реализовать высокоуровневый доступ к данным в ADO только с помощью первичной interop-сборки (PLA) (AD0DB. dll). На рис. 30.1 показано, как эта сборка представляет неуправляемые компоненты СОМ в управляемой среде .NET. Программный код ADO, в сущности, остается неизменным, однако управляться общеязыковой средой выполнения CLR он будет через PLA, а не на уровне операционной системы. Это не диктует необходимость больших изменений в старых реализациях, использующих ADO, хотя некоторые изменения все же придется внести. Это не значит, что современные реализации ADO при их создании в среде .NET будут отличаться от предыдущих. Например, в строке подключения по-прежнему необходимо задавать конкретного поставщика OLE DB; также необходимо знать интерфейсы и требования каждого из них. С другой стороны, вступают в игру конструкторы и уборка мусора, система безопасности и проверка типа среды выполнения.

В этой модели проблемы приложений могут привести к неустойчивости операционной системы. В SQL Server 2005 технология ADO использует сборку adodb. dll для поддержки своего программного кода при обеспечении безопасности клиента управляемой среды .NET Framework. Клиент SQL Native Client (SNAC) оптимизирован для доступа к SQL Server, поскольку он непосредственно взаимодействует с сетевыми службами.

Рис. 30.L Неуправляемые интерфейсы ADO используют “родные” службы MDAC для доступа к данным

Первоочередной задачей программистов является перевод программного кода на рельсы ADO.NET 2.0. Для облегчения этого перехода используйте предлагаемую первичную interop- сборку. Например, как вариант можно рассмотреть поэтапный подход к обновлению приложений до ADO.NET 2.0. Разумный сценарий предполагает использование в приложениях ADO сборки adodb .dll, что требует минимальных изменений в программном коде. При этом приложение получает возможность перемещать структуры из базы данных в наборы данных .NET и потоки XML. Как только структуры оказываются у клиента, открываются возможности для кэширования и управления данными на стороне клиента, равно как и для использования архитектур, ориентированных на службы. Как результат, мы получаем более надежное приложение.

При переводе приложений, использующих ADO, на рельсы .NET Framework не- Совет  обходимо обдуманное планирование. Компания Microsoft в этом отношении по

могла разработчикам тем, что опубликовала в Интернете свои рекомендации относительно перехода от ADO к ADO.NET. В июле-августе 2004 года журнал для разработчиков сайта MSDN опубликовал статью Джона Папа “Migrating from ADO to ADO.NET’. Эта и многие другие статьи из этого информативного журнала доступны бесплатно на сайте

http://msdn.microsoft.com/msdnmag/default.aspx Первая часть вышеупомянутой статьи находится по адресу

http://msdn.microsoft.com/msdnmag/issues/04/07/DataPoints/ default.aspx

Вторая — по адресу

http://msdn.microsoft.com/msdnmag/issues/04/08/DataPoints/ default.aspx

Читателям может также оказаться полезной информация из интерактивной библиотеки MSDN:

http://msdn.microsoft.com/library/default.asp

В заключение, при планировании перехода от ADO к ADO.NET не забудьте заглянуть в утилиту SQL Server Books Online. В содержащейся в ней статье “Updating an Application to SQL Native Client from MDAC” перечислено множество потенциальных проблем, которых можно избежать, если идентифицировать их на ранней стадии миграции.

С момента выхода в свет ADO для поддержки, обслуживания и расширения существующих приложений, использующих ADO, стало не обязательно быть продвинутым программистом СОМ или OLE DB. В то же время для поддержки и отладки многих вопросов, связанных с ADO, полезно иметь четкое понимание механизма работы компонентов СОМ и интерфейса OLE DB. Знание и опыт работы с ADO может пригодиться и в работе с ADO.NET. В конце концов, ADO является базисом, на котором построена ADO.NET; аналогично, OLE DB является основой ADO. Понимание OLE DB поможет вам в работе как с ADO, так и с ADO.NET.

OLE DB

Ключом к пониманию OLE DB являются метафоры потребителя и поставщика, используемые для описания этой технологии. OLE DB — это метод подключения данных поставщика к приложению, потребляющему эти данные. Для создания некоторых распространенных подключений между разными поставщиками и потребителями должны быть выполнены четко очерченные действия. OLE DB представляет собой компонент СОМ СоТуре, или связанную группу интерфейсов СОМ, которые описаны в раскрываемой иерархии, определяемой свойствами и управляемой событиями. В общем случае OLE DB пытается доставить строки и столбцы данных потребителям. Некоторые поставщики не в полной мере соответствуют данному описанию. Иерархия СоТуре является своеобразным трапом, по которому различные типы данных могут подниматься из неизвестных источников данных к потребителю, начиная с разных ступенек трапа и заканчивая точкой доставки, известной как CoCreateInstance. Каждую ступеньку этого концептуального трапа можно рассматривать как потребителя нижней соседней ступеньки и поставщика верхней. Эти переходы в совокупности называют интерфейсами. Все интерфейсы являются наследниками фундаментального интерфейса IUnknown. Это демонстрирует полезность и возможность повторного использования компонентов, поскольку все компоненты СоТуре аналогичны по форме, даже если сильно отличаются функционально. Это легко можно подтвердить, если принять во внимание структурные сходства между разными объектами ADO. На простейшем уровне каждый объект имеет свойства и методы и участвует в иерархии членов.

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

По теме:

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