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

0

Дополнительная Читатели, желающие поближе ознакомиться с иерархиями СоТуре и OLE DB, мо- ииформаиий рут обратиться к статье “Introduction to OLE DB Programing” в библиотеке MSDN:

‘ -•-*?***http: //msdn.microsoft. com/library/default. asp?url =/library/ en-us/oledb/htm/oledbpartl_introduction_to_ole_db.asp

Количество CoTypes в OLE DB крайне велико. Самым мощным и полезным свойством OLE DB является способность выражать и передавать все поставляемые данные потребителю в простейших терминах значения, его длины и отличительных характеристик, таких как состояние. В идеальном случае состоянием будет DBPROPSTATUS_OK (т.е. признак хороших данных), в то же время состояние может указывать среди прочего на пустое значение, испорченные данные или по какому критерию данные считаются испорченными.

OLE DB (как, в принципе, и все другие компоненты СОМ) не зависит от используемых языков программирования. Это делает данный интерфейс идеальной низкоуровневой архитектурой для языков высокого уровня, использующих ADO. Низкоуровневые спецификации способны остаться неизменными, в то время как объектная модель ADO может быть описана в VB, С#, на языках сценариев VBScript и JScript и на языках, способных войти в пространство низкоуровневой спецификации, таких как C++. OLE DB является могучим программным решением, предназначенным для обработки информации из баз данных и прочих источников в наборах записей и потоках. Объектная модель ADO делает интерфейс OLE DB доступным для разработчиков, образуя его оболочку. В то же время ее нельзя назвать окончательным решением доступа к данным.

Если программист неправильно определил область памяти, а компилятор не Внимание! проверяет безопасность типов, могут возникнуть утечки памяти и ошибки доступа к данным, что нарушит устойчивость базы данных и приложения. Утечки памяти возникают, когда приложение выделяет память, но не возвращает ее в пул свободной памяти после того, как потребность в данной области отпала. Ошибки доступа возникают, когда приложение пытается прочитать или записать по адресу, который уже используется другим потоком выполнения. Компилятор C++ в Visual Studio2005 не может проверить корректность ссылок на области памяти, поэтому данный язык не защищает программиста от потенциально опасных дефектов в программном коде. Компиляторы VB.NET и, с некоторой натяжкой, компиляторы С#, равно как и Windows Scripting Host, предлагают более совершенную защиту от таких искажений памяти. Утилита PEVerify, входящая в состав .NET Framework 2.0 SDK, может быть использована для идентификации безопасного для типов кода MSIL. В то же время эта утилита совершенно бесполезна при поиске местонахождения и типов дефектов защиты типов в исходном программном коде.

Первичные interop-сборки AD0DB

СОМ и .NET являются совместимыми технологиями. Сборки .NET могут использоваться в приложениях СОМ, а компоненты СОМ — в программном коде .NET. Сборки .NET могут управляться оболочками СОМ. Оболочка СОМ должна реализовать ядро interop-сборки СОМ. По своей сути interop-сборки являются метаданными (или определениями типов) для компонентов СОМ, выраженными в управляемом коде.

Дополнительную информацию по вопросу интероперабельности компонентов СОМ и .NET вы можете найти в статье “Microsoft .NET/COM Migration and Interoperability”, размещенной по адресу:

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

Первичная interop-сборка (далее PIA) подписывается владельцем объекта COM. PIA является interop-сборкой, рекомендуемой для использования в среде .NET Framework при раскрытии объекта СОМ в управляемом коде. Компания Microsoft предлагает такие подписанные PIA для ADO в среде разработки Visual Studio .NET — они содержатся в сборке adodb .dll. Microsoft рекомендует использовать только эту сборку при использовании ADO в управляемом коде .NET. Как показано на рис. 30.2, все ссылки для первичной interop-сборки выбираются из списка ссылок .NET при добавлении в проект Visual Studio, а не с помощью добавления ссылки на компонент ADO во вкладке СОМ диалогового окна Add Reference.

Следует сделать еще одно замечание, касающееся использования ADO в Visual Studio 2005. Дело в том, что клиент SNAC не поддерживает объектную модель ADO, а это означает, что для доступа к SQL Server приложения ADO должны полагаться исключительно на компоненты MDAC. ADO.NET поддерживается клиентом SNAC и не требует координации со сложной паутиной библиотек и компонентов MDAC.

Рис. 30.2. Выбор adodb. dll в качестве ссылки .NET в проекте Visual Studio

MDAC становится составной частью различных операционных систем от Microsoft и в дальнейшем не будет выходить в свет отдельно от них. Специально установленная библиотека MDAC не используется ни в одном примере этой главы. Здесь используются драйверы MDAC, поставляемые с операционными системами Windows ХР SP2, Windows ХР х64, Windows Server 2003 R2 Standard и Windows Server 2003 R2 Enterprise x64. Вряд ли Microsoft будет выпускать в дальнейшем новые версии обособленных библиотек MDAC. Возможно, лучшим местом отслеживания изменений в MDAC станет документация к новым версиям операционных систем, пакетов ообновления и заплаток. Аналогично, совместимость версий MDAC будет проверяться методом тестирования изменений, примененных к операционной системе.

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

С изменениями в MDAC и SNAC также можно ознакомиться в центре разработчиков Data Access and Storage Developer Center по адресу:

http://msdn.microsoft.com/data/default.aspx

Одним из самых информативных документов, которые можно там найти, является “Data Access Technologies Road Map”:

http://msdn.microsoft.com/data/mdac/default.aspx?pull=/ library/en-us/dnmdac/html/data_mdacroadmap.asp

Объектная модель ADO

До сих пор в этой главе мы говорили о месте ADO в мире .NET и инфраструктуре OLE DB, а также о методах использования ADO в среде .NET Framework. Теперь посмотрим, как ADO вписывается (или более уместно сказать — не вписывается) в общую схему ADO.NET.

Одной из основных задач ADO.NET была реализация всех возможностей, заложенных в старой доброй объектной модели ADO. Как минимум, ADO является ролевой моделью ADO.NET. Версии ADO.NET 1.x предстали перед нами с несколько сокращенным набором возможностей ADO, в результате чего реализация средств .NET была ограничена пространством доступа к данным. С выходом версий ADO.NET 2.0 и SQL Server 2005 полный набор средств ADO был объединен с независимостью и безопасностью среды .NET Framework и перспективами XML. Нельзя сказать, чтобы не требовалось никакой работы и чтобы ADO была полностью реализована в своем потомке, особенно в вопросах производительности. Понять произошедшую трансформацию можно только с помощью сравнения этих двух объектных моделей. Для адекватного сравнения рассмотрим функции и компоненты объектной модели ADO. Это заложит фундамент для последующей оценки того, что появилось нового и что было улучшено в ADO.NET.

Объектная модель ADO является не просто оболочкой интерфейса OLE DB. Она представляет реальную ценность для разработчика и имеет некоторые преимущества перед предыдущими методами доступа к данным. Ниже вкратце перечислены эти преимущества.

?               Независимое создание объектов. В ADO больше нет необходимости последовательно проходить по иерархии объектов. Разработчик создает только необходимый ему объект, таким образом, снижая нагрузку на память, повышая скорость выполнения приложения и уменьшая количество строк программного кода.

?               Пакетное обновление. Вместо отправки на сервер одного сообщения они могут накапливаться в локальной памяти и отправляться одновременно. Использование этой функции повышает производительность приложения (потому что поставщик данных может выполнять обновления в фоновом режиме) и сокращает нагрузку на сеть.

?               Хранимые процедуры. Эти процедуры хранятся и выполняются на серверной стороне СУБД. Они используются для выполнения конкретных задач с наборами данных. ADO использует хранимые процедуры с входными и выходными параметрами и возвращает значения.

?               Множество типов курсоров. Курсоры указывают на строку, с которой выполняется работа в текущий момент. Курсоры могут располагаться как на стороне сервера, так и на стороне клиента.

Дополнительная Очень важно понимать отличия клиентского курсора в приложении и курсора информация Т-SQL. Первые оказывают довольно слабое влияние на производительность.

С другой стороны, использование серверных курсоров, особенно обновляемых, может негативно сказаться на базе данных. Подробно о курсорах см. в главе 20.

?               Ограничение числа возвращаемых строк. Эта функция позволяет ограничить количество возвращаемых запросом строк только теми, которые действительно нужны пользователю.

?               Множество объектов наборов записей. Возможность работы с множеством наборов данных, возвращаемых хранимой процедурой или пакетом инструкций.

?               Свободные потоковые объекты. Эта функция повышает производительность Web- сервера, позволяя ему одновременно выполнять несколько задач.

Подобно всем компонентам OLE DB, ADO использует COM. ADO предоставляет двойственный интерфейс: идентификатор программы ADODB для локальных операций и идентификатор ADOR — для удаленных. Сама библиотека ADO работает со свободными потоками, несмотря на то, что в реестре она показана как использующая модель с разделенными потоками. Безопасность потоков в ADO зависит от используемого поставщика OLE DB. Другими

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

По теме:

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