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

0

SQL Native Client

В версиях SQL Server 2005 и ADO.NET 2.0 доступ к серверу баз данных уже не основывается на MDAC. Вместо этого в одном файле .dll содержится сборка, получившая название SQL Native Client. Ожидалось, что эта сборка решит все известные проблемы согласованности, связанные с распределенным обновлением массивного набора файлов MDAC, а также повысит защищенность за счет сокращения количества доступных интерфейсов. Собственные протоколы компании Microsoft доступа из .NET в SQL Server, равно как и интерфейсы OLE DB, ODBC и собственные интерфейсы SQL Server, также были включены в эту сборку.

Было бы идеально, если бы для доступа к SQL Server требовалась только сборка SQL Native Client. К сожалению, идеал так и остался недостижимым. SQL Native Client поддерживает только SQL Server 7.0 и более поздние версии продукта. SQLXML не интегрирована в SQL Native Client. С большой вероятностью множеству приложений придется сохранить зависимость как от MDAC, так и от SQL Native Client. В конце концов, одним из основных преимуществ платформы .NET является доступ к гетерогенным источникам данных. Монолитный SQL Native Client способен упростить обслуживание и обеспечение безопасности содержащихся в нем интерфейсов, однако он так и не внес существенного сдвига в способе взаимодействия приложений с SQL Server. Аналогично, вероятнее всего, что доступ с помощью ODBC, OLE DB и, в некоторой мере, ADO так и останется проблематичным, поскольку расширение SQL Native Client предполагает зависимость от компонентов MDAC.

Дополнительная В SQL Server 2005 интерфейс SQLXML был обновлен до версии 4.0. Несмотря информация на то что он не интегрирован в поставщик SQL Native Client, SQLXML поддер- " живается средой .NET Framework посредством поставщика SQLXMLOLEDB, основанного на интерфейсе OLE DB. Дополнительную информацию об SQLXML и использовании его в программировании .NET вы найдете в главе 31.

Типы данных

ADO.NET использует XML для перемещения информации из базы данных в приложение. Не следует путать этот транспортный механизм с типом данных XML, поскольку он позволяет доставлять любые данные SQL, подобно тому, как TDS является основным механизмом транспортировки двоичных данных из SQL Server. XML может поддерживать все типы данных, поскольку является потоком битов. В противоположность этому приложения Visual Studio полагаются на управляемые типы данных для представления информации на экране. Другими словами, XML привнес в приложения дополнительный уровень преобразований. ADO.NET перемещает информацию между базой данных и приложениями в потоках XML. После этого поток XML нужно распаковать, чтобы представить реляционные данные приложению в нужном формате. Все ограничения данных и проблемы, рассмотренные в разделах, посвященных ADO, также применимы и к данным, поставляемым в приложение с помощью ADO.NET. Таким образом, на этапе разработки следует уделить особое внимание таким вопросам, как потеря данных и проблемы совместимости.

К счастью, управляемая среда обеспечивает надежное управление типами данных, используемых в СУБД. Использование ADO.NET может несколько понизить общую производительность транспортировки данных, поскольку использование потока XML требует операций упаковки и распаковки. В то же время маловероятно, чтобы в управляемой среде программист столкнулся с какими-либо проблемами преобразования данных. Ожидается, что в ближайшем будущем производительность операций ввода-вывода, использующих потоки XML, станет не хуже производительности передачи двоичных данных, используемой в ADO. Это сразу же поможет обуздать разрастание ошибок преобразования типов данных во время выполнения приложения.

Одной из особо важных причин, почему стоит отдать предпочтение ADO.NET, а не ADO, является то, что ADO.NET лучше поддерживает новые типы данных SQL Server, такие как XML, varchar (шах), varbinary (шах), а также все пользовательские типы CLR.

Дополнительная Полную схему отображения типов данных SQL Server 2005 и среды .NET Frame- информация work см. в табл. 27.1 главы 27.

Тип данных XML в SQL Server 2005 не следует путать с потоками XML, используемыми ADO.NET для транспортировки данных. Тип данных XML поддерживается типом данных System.Data.SqlTypes.SqlXml в ADO.NET2.0. Тип данных XML можно использовать для хранения документов XML и их фрагментов. ADO.NET 2.0 поддерживает чтение этого типа данных с помощью метода XMLDataReader. В отличие от других типов данных SQL Server 2005, тип XML проверяется на уровне SQL Server, а не на уровне ADO.NET. Это значит, что данные с типом XML несут с собой риск генерации ошибок при использовании метода обновления объекта DataAdapter (т.е. когда данные возвращаются в базу), которые невозможны при использовании других примитивных типов данных. SQLXML 4.0 предлагает мощную поддержку типа XML на стороне клиента, включая собственный набор компонентов доступа к данным. Напомню, что SQLXML 4.0 не реализован в составе ADO.NET 2.0.

Пользовательские типы данных CLR заслуживают особого внимания. Для использования этих типов в программном коде .NET структурно целостные версии соответствующих сборок должны существовать как на сервере баз данных, так и на серверах приложений. Это требование ограничивает гибкость решений. Совершенно не обязательно, чтобы строгие имена сборок на серверах баз данных и приложений совпадали, — главное, чтобы структура типа на всех этих серверах была определена одинаково. В этом требовании есть определенный смысл. Системные примитивные типы данных, такие как int, char или bit, должны существовать на всех серверах. Различие заключено в логистике, необходимой для поддержания синхронизации дополнительных свойств пользовательских типов на всех уровнях, в противоположность относительно статичным примитивным типам. Пользовательские типы, используемые только на сервере баз данных, на практике вряд ли будут иметь особую ценность, а пользовательские типы, развернутые в производственной среде, скорее всего, будут хрупкими благодаря своим неудобным требованиям. При использовании пользовательских типов в приложениях ADO.NET 2.0 необходимо тщательное планирование развертывания.

Дополнительная Развернутую дискуссию по вопросам создания и развертывания пользователь- информация ских типов вы найдете в главе 29.

Адаптеры данных и наборы данных

До настоящего момента мы рассматривали технологии ADO и ADO.NET как совершенно различные, несмотря на сходство имен и общее назначение. Ядром модели ADO является класс набора записей Recordset. Для модификации данных с помощью этого набора записей необходимо использовать либо программный интерфейс серверного курсора, который остается в базе данных, либо отправлять обновления в базу данных, как только они произошли в наборе данных. Оба метода доказали свою несостоятельность вследствие наличия вопросов конкуренции; к тому же оба метода требуют большого объема программного кода. Чтобы работать с множеством наборов записей Recordset, необходимо создавать множество подключений и жонглировать этими наборами в программном коде либо организовывать несколько наборов записей из базы данных в коллекцию и работать с ними по очереди. Каждый из методов доказал свою жесткость и требует больших цепочек часто повторяющегося программного кода.

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

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

Объект DataAdapter наполняет объект DataSet из потока данных, идущего из базы. Также он обрабатывает вставки, обновления и удаления, которые должны быть распространены на базу данных.

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

Оптимизация индексов в ADO.NET 2.0 существенно увеличила размеры кэша объекта DataSet, при этом существенно повысив быстродействие по сравнению с ADO.NET Ijc. Объект DataSet, наполняемый относительно небольшим объемом данных, не даст прочувствовать эффект от оптимизации индексов. По мере разрастания объекта DataSet эффект оптимизации станет более явным.

Пакет Visual Studio 2005 хорошо интегрирован с классами ADO.NET 2.0. Техно- Назаметку логия ADO.NET уже стала значительно проще в использовании. Множество средств интерфейса пользователя Visual Studio еще в большей мере упростили использование ADO.NET в приложениях. К примеру, DataSet может быть связан с элементом управления методом перетаскивания этого элемента с панели инструментов на объект элемента управления. К тому же на этапе разработки можно воспользоваться услугами мастеров объектов DataAdapter и DataSet, которые позволяют автоматически создавать наборы данных и программный код для их наполнения.

Метод CommandBuild позволяет автоматически создавать команды обновления, вставки и удаления, которые будет использовать объект DataAdapter для работы с базой данных, на основе инструкции SELECT, использованной для заполнения объекта DataSet. Одна строка программного кода поможет сгенерировать три операции над базой данных.

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

По умолчанию класс DataReader использует односторонний последовательный курсор. Этот объект предлагает работу как в подключенном, так и в отключенном режиме. Пользователь может загрузить данные из базы компании, используя доступное подключение (в том числе и через Интернет). После этого в отключенном режиме данные будут доступны для просмотра (но не для непосредственной модификации, так как связь с базой данных была потеряна). В то время как пользователя может в большей мере заинтересовать использование обособленного объекта DataReader, ADO.NET 2.0 дополнительно предлагает методы преобразования объекта таблицы DataTable в DataReader с помощью метода GetTableReader, а также наполнения объекта DataTable из объекта DataReader или подключенного к базе данных объекта DataAdapter. Повышенная гибкость и сокращение объема программного кода, сопровождающие это усовершенствование класса DataTable, являются дополнительными причинами, по которым лучше использовать модель ADO.NET, чем ADO.

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

City = dsOrder.Tables[n].Rows[л].ItemArray.GetValue(1).ToSTringO

Используя типизированный объект DataSet модели ADO.NET, программный код можно сделать более дружественным:

City = dsOrder.Invoice[0].Name;

Как мы видим, ссылки на типизированные объекты DataSet более краткие.

В то же время объекты Recordset модели ADO требуют меньшего объема программного кода для доступа к отдельным значениям. Кроме того, при использовании объекта Recordset к полям можно обращаться по имени, в то время как DataSet или обособленный объект DataTable требует указания индекса, основанного на порядковом номере значения в результирующем наборе данных. Использование ADO.NET предлагает и другие существенные преимущества, которые можно сразу не заметить, если позволить предубеждению, что “все равно ADO лучше”, омрачить общую картину.

Модель ADO.NET 2.0 также предлагает использование множественного активного результирующего набора данных (MARS), доступного только для работы с SQL Server 2005. MARS можно себе представить как механизм создания пула сессий, подобно механизму создания пула подключений в технологии ADO. Так как существует масса причин создания множества подключений, в некоторых случаях (например, когда несколько запросов должны поддерживать целостность транзакции) MARS может обеспечить целостность транзакций и повысить производительность без необходимости разделения транзакции на два этапа, использующих разные подключения. Если в поставщике данных включена поддержка MARS, то инструкции отбора данных могут чередоваться согласно требованиям поставленной задачи. В операциях вставки, обновления и удаления, выполняемых со включенной поддержкой MARS, происходит сериализация инструкций DML и отбора данных. По умолчанию в SQL Server 2005 отключена поддержка MARS. Чтобы ее включить, достаточно задать в строке подключения параметр MultipleActiveResultSets=true.

Даже несмотря на то, что MARS по умолчанию отключен, для его поддержки На заметку все подключения подвергаются дополнительной нагрузке. Компания Microsoft заявляет, что установка параметра MultipleActiveResultSets в значение false не исключает эту нагрузку. Пожалуй, единственным основанием отключения поддержки MARS является необходимость генерирования состояния ошибки, когда в одном подключении отправляется больше одного запроса.

Модель ADO не реализует функции удаленного подключения. Но, подобно всем остальным технологиям, основанным на СОМ, она использует объектную модель распределенных компонентов DCOM как основу обмена данными в удаленных сетях. Это значит, что номер порта подключения часто изменяется и что сами данные имеют двоичную форму. Преимуществом этого подхода является то, что только немного взломщиков имеют знания, необходимые для просмотра данных (разумеется, если они после обнаружения данных смогут их дешифровать). Недостатками являются невозможность использования некоторых специфичных для ADO.NET функций, высокие технические затраты на передачу двоичных данных и невозможность прохождения через брандмауэры Web-cepeepa. Хорошо сконфигурированный брандмауэр закрывает порты и ограничивает прохождение двоичных данных.

. Проще говоря, DCOM — это технология СОМ, в которой компоненты могут В взаимодействовать по сети. В DCOM компоненты для взаимодействия исполь- ^V/ХСети зуют технологию удаленного вызова процедур (RPC). На практике защита и ин- ^             теграция со стеком сетевых протоколов отдаляют технологию DCOM от СОМ,

несмотря на то, что они имеют сходное назначение. Читателям, которым интересно детально ознакомиться с технологией DCOM, я бы посоветовал прочитать статью “DCOM Technical Overview”, опубликованную в 1996 году на сайте библиотеки MSDN:

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

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

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

?               Автоматическая эскалация транзакций из локальных в распределенные, когда в них задействовано множество источников данных.

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

?               Обновления из наборов данных DataSet могут быть отправлены в базу данных пакетами. Для этого свойство UpdateBatchSize адаптера данных SQLDataAdapter следует установить в значение больше нуля.

?               Улучшенный поиск доступных источников данных. Например, объект SqlClient предназначен для поиска всех доступных экземпляров SQL Server в локальной сети.

?               Улучшенное управление пулом подключений, в том числе возможность установки ограничений на количество подключений и очистки пула от всех существующих подключений.

?               Программный интерфейс массовой вставки, основанный на ADO.NET 2.0, позволяет быстро переместить большие объемы данных из объектов DataTable и DataReader.

?               ADO.NET 2.0 может служить источником данных для пакетов службы интеграции.

?               Метод уведомлений, используемый для информирования процессов среднего уровня об изменении данных в базе. Это еще раз подчеркивает достоинства многоуровневой архитектуры, где наборы данных кэшируются, а исходные данные быстро меняются. Объект SqlDependency связан с объектом Sql Command. После этого приложение с помощью метода SQLNotif icationRequest опрашивает очередь брокера служб на предмет наличия уведомлений об обновлении данных.

?               Возможность асинхронного выполнения. Способность создавать новые рабочие потоки, одновременно продолжая обработку в основном потоке, не является новой, за исключением возможности перечисления и управления асинхронными рабочими потоками. Связанные методы запросов теперь поддерживают типичную программную структуру .NET begin. . . end для асинхронных операций (например, BeginExecuteNonQuery. . . EndExecuteNonQuery). Следует обратить внимание, что WinForms не поддерживает асинхронные очереди ADO.NET 2.0. Асинхронное выполнение по умолчанию отключено. Для его включения в строке подключения нужно установить параметр AsynchronousProcessing=true.

?               Метрика производительности SQL Server представлена в интерфейсе программирования как свойство подключения.

Дополнительная Четыре важных расширения ADO.NET могут быть использованы в серверном

информация коде CLR: SqlContext, SqlPipe, SqlTriggerContext и SqlDataRecord. Все они детально описаны в главе 27.

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

По теме:

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