Эндрю Троелсен - ЯЗЫК ПРОГРАММИРОВАНИЯ С# 2005 И ПЛАТФОРМА .NET 2.0. 3-е издание

Замечание.В .NET 2.0 сериализация типов DataSet (и DataTable) может выполняться в двоичном формате (с помощью RemotingFormat). Это может оказаться полезным при построении распределенных систем на уровне удаленного взаимодействия .NET (см. главу 18), поскольку двоичные данные оказываются гораздо более компактными, чем данные XML

Но, возможно, самым главным различием между классической схемой ADO и ADO.NET оказывается то, что ADO.NET является управляемой библиотекой программного кода, которая, следовательно, подчиняется правилам, сформулированным для любой управляемой библиотеки. Типы, включенные в ADO.NET, используют тот же протокол управления памятью CLR, ту же систему типов (классы, интерфейсы, перечни, структуры и делегаты) и так же открыты для доступа любому языку .NET.

Библиотеки ADO.NET могут использоваться в рамках одного из двух концептуально различных способов взаимодействия: на связном или несвязном уровнях. При использовании связного уровня ваш программный код непосредственно соединяется с соответствующим хранилищем данных (и отсоединяется от него, когда задачи взаимодействия решены). При использовании ADO.NET в такой форме для взаимодействия с хранилищем данных обычно используются объекты соединения, объекты команд и объекты чтения данных. Позже вы сможете убедиться в том. что объекты чтения данных обеспечивают способ извлечения записей из хранилища данных на основе подхода, допускающего только чтение в режиме однонаправленного доступа.

Несвязный уровень, напротив, позволяет получить набор объектов DataTable (содержащихся в рамках DataSet), функционирующих, как клиентские копии внешних данных. При получении DataSet с помощью соответствующего объекта адаптера данных необходимое вам соединение открывается и закрывается автоматически. Вы можете сами догадаться, что данный подход позволяет быстрее освободить соединение для других вызывавших абонентов. После получения объекта DataSet клиентом этот клиент может просматривать и менять содержимое объекта, не создавая лишней нагрузки на сетевой трафик. Чтобы направить измененные данные обратно в хранилище данных, клиент может снова использовать адаптер данных (в совокупности с множеством подходящих операторов SQL), и после обновления источника данных соединение снова немедленно разрывается.

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

Упрощенно говоря, поставщик данных - это набор типов, определенных в дан-ном пространстве имен и "понимающих", как общаться с конкретным источником данных. Любой используемый нами поставщик данных определяет набор типов, обеспечивающих базовые функциональные возможности. В табл. 22.1 описаны некоторые базовые объекты, их базовые классы (все они определяются в пространстве имен System.Data.Common) и реализованные в них интерфейсы (они определяются в System.Data).

Таблица 22.1. Базовые объекты поставщика данных ADO.NET

Хотя имена соответствующих типов для разных поставщиков данных оказываются разными (например, SqlConnection, OracleConnection, OdbcConnection и MySqlConnection), каждый из таких объектов получается из одного и того же базового класса, что предполагает идентичность реализуемых объектами интерфейсов. С учетом этого мы вправе предполагать, что, освоив приемы работы с одним поставщиком данных, освоить остальные поставщики будет совсем просто.

Замечание.В соответствии с соглашением о присваивании имен объекты поставщика данных должны иметь префикс, указывающий имя соответствующей СУБД.

На рис. 22.1 показана общая структура поставщика данных ADO.NET. Заметьте, что в представленной диаграмме элемент Компоновочный блок клиента может обозначать практически любое приложение .NET – консольную программу, приложение Windows Forms, Web-страницу ASP.NET, Web-сервис XML, библиотеку программного кода .NET и т.д.

Конечно, в дополнение к объектам, показанным на рис. 22.1, поставщик данных предлагает и другие типы объектов. Однако указанные на рисунке базовые объекты присущи всем поставщикам данных.

В дистрибутив Microsoft .NET 2.0 включен ряд поставщиков данных, в частности для Oracle, SQL Server и ODBC. В табл. 22.2 для поставщиков данных Microsoft ADO.NET указаны пространства имен и содержащие их компоновочные блоки.

Замечание.Специального поставщика данных, обращающегося непосредственно к механизму Jet (т.е. к Microsoft Access), нет. Для взаимодействия с файлами данных Access можно использовать поставщик данных OLE DB или ODBC.

Рис 22.1. Поставщики данных ADO.NET обеспечивают доступ к данным СУБД.

Таблица 22.2. Поставщики данных ADO.NET от Microsoft

Поставщик данных OLE DB, который скомпонован из типов, определенных в пространстве имен System.Data.OleDb, позволяет получить доступ к данным любого 'хранилища данных, поддерживающего классический протокол OLE DB на основе COM. С помощью этого поставщика данных можно связаться с любой базой данных OLE DB, просто настроив сегмент Provider строки соединения. При этом, однако, следует учитывать то, что поставщик OLE DB в фоновом режиме взаимодействует с различными объектами COM, а это может влиять на производительность приложения. В общем, поставщик данных OLE DB оказывается полезным только в том случае, когда приходится взаимодействовать с СУБД, не определяющей конкретного поставщика данных .NET.