Технология доступа к данным ado net. Технологии ADO.NET

Последнее обновление: 31.10.2015

Сегодня большое значение имеет работа с данными. Для хранения данных используются различные системы управления базами данных: MS SQL Server, Oracle, MySQL и так далее. И большинство крупных приложений так или иначе используют для хранения данных эти системы управления базами данных. Однако чтобы осуществлять связь между базой данных и приложением на C# необходим посредник. И именно таким посредником является технология ADO.NET.

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

Причем важно отметить, что систем управления баз данных может быть множество. В своей сущности они могут различаться. MS SQL Server, например, для создания запросов использует язык T-SQL, а MySQL и Oracle применяют язык PL-SQL. Разные системы баз данных могут иметь разные типы данных. Также могут различаться какие-то другие моменты. Однако функционал ADO.NET построен таким образом, чтобы предоставить разработчикам унифицированный интерфейс для работы с самыми различными СУБД.

Основу интерфейса взаимодействия с базами данных в ADO.NET представляет ограниченный круг объектов: Connection, Command, DataReader, DataSet и DataAdapter. С помощью объекта Connection происходит установка подключения к источнику данных. Объект Command позволяет выполнять операции с данными из БД. Объект DataReader считывает полученные в результате запроса данные. Объект DataSet предназначен для хранения данных из БД и позволяет работать с ними независимо от БД. И объект DataAdapter является посредником между DataSet и источником данных. Главным образом, через эти объекты и будет идти работа с базой данных.

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

По умолчанию в ADO.NET имеются следующие встроенные провайдеры:

    Провайдер для MS SQL Server

    Провайдер для OLE DB (Предоставляет доступ к некоторым старым версиям MS SQL Server, а также к БД Access, DB2, MySQL и Oracle)

    Провайдер для ODBC (Провайдер для тех источников данных, для которых нет своих провайдеров)

    Провайдер для Oracle

    Провайдер EntityClient. Провайдер данных для технологии ORM Entity Framework

    Провайдер для сервера SQL Server Compact 4.0

Кроме этих провайдеров, которые являются встроенными, существует также множество других, предназначенных для различных баз данных, например, для MySQL.

Основные пространства имен, которые используются в ADO.NET:

    System.Data: определяет классы, интерфейсы, делегаты, которые реализуют архитектуру ADO.NET

    System.Data.Common: содержит классы, общие для всех провайдеров ADO.NET

    System.Data.Design: определяет классы, которые используются для создания своих собственных наборов данных

    System.Data.Odbc: определяет функциональность провайдера данных для ODBC

    System.Data.OleDb: определяет функциональность провайдера данных для OLE DB

    System.Data.Sql: хранит классы, которые поддерживают специфичную для SQL Server функциональность

    System.Data.OracleClient: определяет функциональность провайдера для баз данных Oracle

    System.Data.SqlClient: определяет функциональность провайдера для баз данных MS SQL Server

    System.Data.SqlServerCe: определяет функциональность провайдера для SQL Server Compact 4.0

    System.Data.SqlTypes: содержит классы для типов данных MS SQL Servera

    Microsoft.SqlServer.Server: хранит компоненты для взаимодействия SQL Server и среды CLR

Схематично архитектуру ADO.NET можно представить следующим образом:

Функционально классы ADO.NET можно разбить на два уровня: подключенный и отключенный. Каждый провайдер данных.NET реализует свои версии объектов Connection, Command, DataReader, DataAdapter и ряда других, который составляют подключенный уровень. То есть с помощью них устанавливается подключение к БД и выполняется с ней взаимодействие. Как правило, реализации этих объектов для каждого конкретного провайдера в своем названии имеют префикс, который указывает на провайдер:

Другие классы, такие как DataSet, DataTable, DataRow, DataColumn и ряд других составляют отключенный уровень, так как после извлечения данных в DataSet мы можем работать с этими данными независимо от того, установлено ли подключение или нет. То есть после получения данных из БД приложение может быть отключено от источника данных.

Сегодняшний век высоких технологий и научных достижений диктует высокий темп развития всех отраслей и наук, что привело к автоматизации большинства сфер жизни современного человека. Как у и любого процесса у автоматизации есть и положительные и отрицательные стороны. Одну из этих сторон, а именно упрощает ли автоматизация трудовую деятельность людей, рассмотрим в дальнейшем подробней. С точки зрения любого руководителя автоматизация уменьшает издержки на производство и повышает эффективность работоспособности всей организации в целом. Но с точки зрения людей, которые разрабатывают системы автоматизации ситуация достаточно сложна, так как в основе любой информационной системы лежит база данных, а точнее СУБД. И выбор той или иной СУБД будет влиять на дальнейшие функциональные возможности информационной системы и то, как она будет спроектирована. А на сегодняшний день насчитывается около двух десятков различных СУБД. И перед разработчиком стает сложный выбор, какаю СУБД использовать. А знать особенности проектирования при каждой СУБД непосильная задача даже для целого отдела разработчиков.

Ситуация еще усугубляется когда необходимо обеспечить поддержку различных источников данных. При чем каждый из таких источников данных может хранить и обрабатывать данные по-своему. Еще необходимо учитывать, что в различных языках программирования различна поддержка работы с той или иной СУБД.

То есть, еще возникает проблема не соответствия обработки информации большинством СУБД и способом обработки информации различными языками программирования.

Решение выдвинутых проблем найдено в новой технологии ADO.NET, разработанной компанией Microsoft, и включенной в их новую платформу.NET Framework.

Цели и задачи

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

ADO.NET

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

В NET Framework библиотеки ADO.NET находится в пространстве имени System.Data. Эти библиотеки обеспечивают подключение к источникам данных, выполнении команд, а также хранилище, обработку и выборку данных (рис 1.2).

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

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

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

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

Хотя ADO.NET и ADO - это полностью различные архитектуры доступа к данным.

Объекты ADO.NET

Как и любая другая технология, ADO.NET состоит из нескольких важных компонентов. Все классы.NET группируются в пространства имен. Все функции, относящиеся к ADO.NET находятся в пространстве имен System.Data. Кроме того, как и любые другие компоненты.NET, ADO.NET работает, не изолировано и может взаимодействовать с различными другими компонентами.NET.

Архитектуру ADO.Net можно разделить на две фундаментальные части: подключаемую и автономную. Все классы в ADO.NET можно поделить по этому критерию. Единственное исключение - класс DataAdapter, который является посредником между подключенной и автономной частями ADO.Net.

Поставщики данных.NET

Подключаемая часть ADO.Net представляет собой набор объектов подключений.

Объекты подключений разделяются в ADO.NET по конкретным реализациям для различных СУБД. То есть для подключения к базе данных SQL SERVER имеется специальных класс SqlConnection.

Эти отдельные реализации для конкретных СУБД называются поставщиками данных.NET

При наличии широкого выбора доступных источников данных ADO.NET должна иметь возможность поддерживать множество источников данных. Каждый такой источник данных может иметь свои особенности или набор возможностей.

Поэтому ADO.NET поддерживает модель поставщиков. Поставщики для конкретного источника данных можно определить как совокупность классов в одном пространстве имен созданных специально для данного источника данных. Эта особенность несколько размыта для источников данных OleDb, ODBC, так как они по своей сути созданы для работы с любой базой данных совместимых с OLE и ODBC.

Подключаемые классы и объекты.

В подключаемой части ADO.NET имеются следующие основные классы:

  • Connection . Этот класс, позволяющий устанавливать подключение к источнику данных. (OleDbConnection, SqlConnection, OracleConnection)
  • Transaction . Объект транзакций (OleDbTransaction, SqlTransaction, OracleTransaction. В ADO.NET имеется пространство имен System.Transaction)
  • DataAdapter . Это своеобразный шлюз между автономными и подключенными аспектами ADO.NET. Он устанавливает подключение, и если подключение уже установлено, содержит достаточно информации, чтобы воспринимать данные автономных объектов и взаимодействовать с базой данных. (DataAdapter - SqlDataAdapter, OracleDataAdapter)
  • Command . Это класс представляющий исполняемую команду в базовом источнике данных.
  • Parameter . Объект параметр команды.
  • DataReader . Это эквивалент конвейерного курсора с возможностью только чтения данных в прямом направлении.

Поведение объектов подключения

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

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

Строка подключения содержит элементы с минимальной информацией, необходимой для установления подключений, в виде последовательности пар ключей - значений. Различные пары ключей - значений в строке подключений могу определять, некоторые конфигурируемы параметры, определяющие поведение подключения.

Сам объект подключения источника данных наследуется от класса DbConnection и получает уже готовую логику, реализованную в базовых классах.

Приложение должно разделять дорогостоящий ресурс - открытое подключение - и совместно использовать его с другим пользователем. Именно для этих целей и был введен пул подключений. По умолчанию пул подключений включен. При запросе ADO.NET неявно проверяет, имеется ли доступное неиспользуемое физическое подключение к базе данных. Если такое подключение имеется, то она использует его. Для принятия решения имеется ли такое физическое подключение или нет ADO.Net учитывает загрузку приложения, и если поступает слишком много одновременных запросов, ADO.Net может удерживать одновременно открытыми несколько физических подключений, то есть увеличивать при необходимости количество подключений. Если детально рассмотреть картину, то ситуация такова:

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

Вторым наиболее ресурсоемким объектом в ADO.NET являются транзакции, отвечающие за корректность изменений в БД.

Транзакции

Транзакции - это набор операций, которые для обеспечения целостности и корректного поведения системы должным быть выполнены успешно или неудачно только все вместе.

Обычно транзакции следуют определенным правилам, Известным как свойства ACID: неделимой (Atomic), согласованной (Consistent), изолированной (Isolated) и долговечной (Durable).

Иногда при разработке ПО возможны ситуации, когда нужно изменить некоторые характеристики. В частности, можно изменить принцип изолированности. А управлять неделимостью транзакции можно с помощью таких конструкций, как вложенные транзакции. Но отступать от этих признаков следует только после тщательного анализа.

В ADO.NET реализован мощный механизм поддержки транзакций БД. Сама ADO.NET поддерживает транзакции одиночной БД, которые отслеживаются на основании подключений. Но она может задействовать пространство имен System.Transactions для выполнения транзакций с несколькими БД или транзакций с несколькими диспетчерами ресурсов.

В ADO.NET класс подключений используется просто для начала транзакции.

Все управляемы NET поставщики, доступные в NET Framework OleDb, SqlClient, OracleClient, ODBC имеют свои собственные реализации класса транзакций.

Все эти классы реализуют интерфейс IDbTransaction из пространства имен System.Data.

Если при работе с транзакцией в момент возникновении ошибки не будет произведен откат, то сама среда вызовет метод Rollback, но произведет она это лишь при закрытии или повторном использовании соответствующего физического подключения.

Подключение к БД необходимо производить перед вызовом метода BeginTransaction класса Connection. Так как в данном случае ресурс физического подключения используется меньше, что уменьшает нагрузку на СУБД.

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

Для гибкого управления поведением транзакций используется уровни изоляции.

Уровни изоляции - это степень видимости внутри транзакции изменений, выполненных за пределами этой транзакции. Он определяют, насколько чувствительна транзакция к изменениям, выполненным другими транзакциями.

Например, если в SQL Server две транзакции запущенны, не зависимо одна от другой, то по умолчанию записи, вставленные одной транзакцией, не видны в другой, пока первая транзакция не будет зафиксирована.

Концепция уровней изоляции тесно связана с концепцией блокировок: определив уровень изоляции транзакции - получаем информацию о том, как долго эта транзакция будет блокировать другие ресурсы, чтобы защищать их от изменений, которые могут быть сделаны другими операциями.

Может понадобиться такое поведение транзакций, чтобы вторая транзакция могла видеть записи, вставленные первой. В этом случае возможна ситуация:

  1. Неверного извлечения данных, называемое "грязным чтением"
  2. "Невоспроизводимое чтение" - это состояние, когда транзакция, ранее работающая с данными, пытается вновь осуществить с этими данными взаимодействие, но между этими взаимодействиями другая транзакция произвела изменения данных, при этом первая транзакция работает уже с низменными данными.
  3. "Фантомные строки" - пусть транзакция А работает с набором из 100 строк выбранные по определенные критерием, а транзакция. Б изменяет данные, в результате чего при повторной выборке транзакцией А она имеет уже другой набор строк.

В ADO.NET уровни транзакций описаны в перечислении IsolationLevel:

  • Chaos. Ожидающие записи изменения транзакций более высоких уровней изоляций не могут быть перезаписаны. Это параметр не поддерживается в SQL Server и Oracle
  • ReadUncommited. Разрешается "грязное чтение". Пример использования: мониторинг системы администратором.
  • ReadCommited. Пока транзакция читает данные, удерживается "разделяемые блокировки. Это позволяет избежать "грязного чтения", но данные могут быть изменены до завершения транзакции. В результате может возникнуть "невоспроизводимое чтение". Или может возникнуть "фантомные строки". Этот уровень изоляции поддерживается в Oracle и SLQ Server.
  • RepeatableRead. В этом случае разделяемые блокировки устанавливаются на все данные, используемые в предикате (критерии) запроса. Это предотвращает модификацию данных другими транзакциями и невоспроизводимое чтение. Однако возможны и фантомные строки. Этот уровень изоляции не поддерживается в Oracle.
  • Snapshot. Этот уровень изоляции уменьшает вероятность установки блокировки строк, сохраняя копию данных, которые одно приложение может читать, в то время как другое модифицирует эти же данные.
  • Serializable. В этом случае данные блокируются, что предотвращает обновление или вставку строк в DataSet другими пользователя до тех пор, пока транзакция не завершится. Эту блокировку можно установить на строку, страницу или таблицу. Данный уровень изоляции поддерживается в Oracle

При откате транзакции происходит аннулирование эффекта каждой операции транзакции. В некоторых случаях не требуется отменять все операции - значит, нужен механизм отката только части транзакцию. Это можно реализовать с помощью "точек сохранения".

Точки отката - это маркеры, реализующие роль закладок. Во время выполнения транзакции, можно поместить какую-либо точку, и затем выполнить откат к этой точки вместо полного отката всей транзакции. Для этих целей предусмотрен метод Save в объекте транзакции. Но надо отметит, что данный метод доступен лишь для подключений к SQL SERVER. Поставщик Oracle не поддерживает точки сохранения, но их всегда можно реализовать через прямые запросы или используя хранимые процедуры.

Но есть несколько моментов делающее точки сохранения не очень удобными. Одна из них заключается в том, что необходимо вызывать методы Commit Rollback при откате транзакции к одной из точек сохранения. Еще на что стоит обратить внимание, что после отката транзакции к определенной точке, все точки отказа находящиеся за текущей теряются. И если возникнет в них потребность, их придется установить заново.

Подведя итог, получается, что точки отката позволяют организовать откат транзакции в виде последовательности действий, для каждого из которых можно производить индивидуальных откат. А вложенные транзакции дают возможность организовывать иерархию таких действий. В случае вложенных транзакций одна транзакция включает в себя одну или несколько других транзакций. Но вложенные транзакции доступны лишь объекта подключения типа OleDb.

При работе с разнородными данными используют распределенные транзакции - это транзакции, охватывающие несколько ресурсов.

В распределенных транзакциях могут быть блоки, называtvst диспетчерами ресурсов (resource manager - RM). Но кроме этих диспетчеров необходимо приложение, прислушивающиеся к ним и координирующие их действия. Оно называется координатором распределенных транзакций (Distributed Transaction Coordinator - DTC) или диспетчером транзакций.

Координатор транзакций, которых представлен с Windows, называется координатором распределенных транзакций Microsoft (MSDTC) и представляет собой службу Windows, которая выполняет координацию транзакций для распределенных транзакций.

Типичное выполнение распределенной транзакции заключается в следующих шагах:

  • Приложение начинает транзакцию, запрашивая ее у MSDTC. Это приложение обычно называется инициатором.
  • Затем приложение предлагает RM выполнить свою работу в составе этой транзакции, и диспетчеры ресурсов регистрируются в диспетчере транзакций в качестве части этой же транзакции. Обычно это называется включением и занесением в транзакцию.
  • Если все нормально, то приложение фиксирует транзакцию.
  • Если что-то не так, каждый шаг может выполнять откат.
  • в любом случае, координатор транзакций координирует работу всех RM, чтобы обеспечить, что-либо все они завершились успешно и выполнили нужную работу, либо все они отменили результаты своей работы.

При работе с распределенными транзакциями различные RM должны реализовывать надежный протокол фиксации: наиболее распространенная реализация такого протокола называется двух фазной фиксацией (two-phase commit).

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

Автономные классы и объекты

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

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

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

Можно выделить несколько основных классов автономной модели ADO.NET:

  • DataSet . Класс DataSet является ядром автономного режима доступа к данным в ADO.NET. Лучше всего рассматривать, как будто в нем есть своя маленькая СУБД, полностью находящаяся в памяти.
  • DataTable . Больше всего этот класс похож на таблицу БД. Он состоит из объектов DataColumn, DataRow, представляющих из себя строки и столбцы.
  • DataView . Это объект представлений базы данных.
  • DataRelation . Этот класс позволяет задавать отношения между различными таблицами, с помощью которых можно проверять соответствие данных из различных таблиц.

Заключение

Технология ADO.NET в полной мере способна предоставить механизм для доступа к любому источнику данных, тем самым, предоставляя разработчику мощный механизм взаимодействия с базами данных способный в полной мере реализовать все потребности, возникающие при проектировании ИС.

Технологии ADO .NET, . NET FrameWork, CORBA

Технология доступа к удаленным базам данных ADO .NET была разработана также для архитектуры клиент - сервер. Кроме двух уров­ней удаленных баз данных - клиентского и серверного - появля­ются дополнительные уровни - серверы бизнес-логики, реализу­ющие бизнес-логику приложений.

Технология ADO .NET устанавливает следующую схему рабо­ты клиента с сервером баз данных:

Установка соединения с сервером;

Получение необходимых данных;

Закрытие соединения;

Обработка данных;

Установка соединения для передачи измененных данных об­ратно на сервер.

Основу ADO .NET составляют два основных модуля:

Провайдер данных (Data Provider .NET FrameWork)

Резидентная реля­ционная база данных (DataSet).

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

а) Connection используется для установления соединения с источ­ником данных, а также для управления транзакциями.

б) Command позволяет манипулировать данными источника, а также выполнять хранимые процедуры. При этом могут ис­пользоваться параметры для передачи данных в обоих направ­лениях.

в) DataAdapter служит связующим звеном между резидентной БД DataSet и источником данных и использует обычно объект Command для выполнения команд SQL как при заполнении DataSet данными, так и при обратной передаче измененных клиентом данных к источнику. Для выполнения этих функций в нем имеют­ся четыре метода: SelectCommand, InsertCommand, UpdateCommand и DeleteCommand.

г) DataReader обеспечивает получение данных от источника только для считывания. Если приложение клиента не модифицирует данные и не требуется произвольная выборка данных, а достаточно их однократного просмотра, то использование DataReader вместо DataSet позволит сохранить ресурсы компьютера, а также повы­сить быстродействие приложения.

Резидентная реляционная база данных представляет собой по­лученную клиентом реляционную БД, которая сохраняется в его резидентной оперативной памяти.

Далее клиент в автономном режиме производит обработку дан­ных и при необходимости модифицирует их, после чего снова устанавливается соединение с сервером и модифицированная информация из резидентной базы данных передается обратно.

Такая схема взаимодействия в некоторой степени походит на работу архитектуры файл -

сервер и часто применяется предприятиями при работе с удален­ными базами данных через глобальную сеть Интернет.

Для обеспечения доступа к объектам через глобальную сеть Ин­тернет в составе ADO .NET и был предусмотрен модуль.NET FrameWork обеспечивающий взаимодействие между различными форматами представления данных, в том числе HTML и XML.

Из указанных характеристик видно, что технология ADO .NET обеспечивает:

Возможность взаимодействия между данными различных фор­матов, в том числе HTML и XML;

Значительное снижение затрат при работе с удаленными ба­зами данных через глобальную сеть Интернет.

Обзор ADO.NET

ADO.NET - нечто большее, чем надстройка над каким-нибудь существующим API-интерфейсом. Сходство с ADO минимально; классы и методы доступа к данным довольно существенно отличаются.

ADO (ActiveX Data Objects) - это библиотека компонентов СОМ, получившая в последние несколько лет множество воплощений. ADO состоит, прежде всего, из объектов Connection, Command, Recordset и Field. С помощью ADO открывается соединение с базой данных, после чего некоторые данные извлекаются и помещаются в набор записей, состоящих из полей; эти данные затем претерпевают манипуляции и обновления на сервере, после чего соединение закрывается. Кроме того, ADO предлагает так называемый отключенный набор записей (disconnected record set) , который используется, когда соединение с базой нежелательно удерживать открытым в течение длительного времени.

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

Более того, если вы используете SQL Server, существует замечательный набор управляемых классов, которые настроены на обеспечение максимальной производительности базы данных. Одного этого достаточно для перехода на ADO.NET.

ADO.NET поставляется с тремя пространствами имен клиента базы данных: одно для SQL Server , другое для источников данных Open Database Connectivity (ODBC) и третье для любой базы данных, доступной через OLE DB . Если выбрана база данных, отличная от SQL Server, отдавайте предпочтение OLE DB, если только не окажется, что нет другого выбора кроме ODBC. Если в качестве базы данных используется Oracle, можете посетить сайт Oracle .NET Developer и получить там их поставщика.NET - ODP.NET на странице www.oracle.com/technology/tech/windows/odpnet/index.html .

С точки зрения программиста, тело ADO.NET составляет базовая сборка с именем System.Data.dll . В этом двоичном файле находится значительное количество пространств имен, многие из которых представляют типы конкретного поставщика данных ADO.NET:

Большинство шаблонов проектов Visual Studio 2010 автоматически ссылаются на эту ключевую библиотеку доступа к данным. Однако для импортирования нужных пространств имен необходимо изменить кодовые файлы, например:

Using System; using System.Data; using System.Data.SqlClient; ...

Учтите также, что кроме System.Data.dll, существуют и другие ориентированные на ADO.NET сборки (например, System.Data.OracleClient.dll и System.Data.Entity.dll ), которые необходимо вручную указывать в текущем проекте с помощью диалогового окна Add Reference (Добавление ссылки).

Три стороны ADO.NET

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

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

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

Поставщики данных в ADO.NET

Поставщик данных (data provider) - это набор классов ADO.NET, которые позволяют получать доступ к определенной базе данных, выполнять команды SQL и извлекать данные. По сути, поставщик данных - это мост между вашим приложением и источником данных.

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

Основные объекты поставщиков данных ADO.NET
Тип объекта Базовый класс Соответствующие интерфейсы Назначение
Connection DbConnection IDbConnection Позволяет подключаться к хранилищу данных и отключаться от него. Кроме того, объекты подключения обеспечивают доступ к соответствующим объектам транзакций
Command DbCommand IDbCommand Представляет SQL-запрос или хранимую процедуру. Кроме того, объекты команд предоставляют доступ к объекту чтения данных конкретного поставщика данных
DataReader DbDataReader IDataReader, IDataRecord Предоставляет доступ к данным только для чтения в прямом направлении с помощью курсора на стороне сервера
DataAdapter DbDataAdapter IDataAdapter, IDbDataAdapter Пересылает наборы данных из хранилища данных к вызывающему процессу и обратно. Адаптеры данных содержат подключение и набор из четырех внутренних объектов команд для выборки, вставки, изменения и удаления информации в хранилище данных
Parameter DbParameter IDataParameter, IDbDataParameter Представляет именованный параметр в параметризованном запросе
Transaction DbTransaction IDbTransaction Инкапсулирует транзакцию в базе данных

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

В ADO.NET термин "объект подключения" на самом деле относится к конкретному типу, порожденному от DbConnection; объекта подключения "вообще" нет. То же можно сказать и об "объекте команды", "объекте адаптера данных" и т.д. По соглашению имена объектов в конкретном поставщике данных имеют префиксы соответствующей СУБД (например, SqlConnection, OracleConnection, SqlDataReader и т.д.).

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

В рамках.NET Framework поставляется небольшой набор из четырех поставщиков:

SQL Server

Предоставляет оптимизированный доступ к базам данных SQL Server (версии 7.0 и выше).

OLE DB

Предоставляет доступ к любому источнику данных, который имеет драйвер OLE DB. Это включает базы данных SQL Server версий, предшествующих 7.0.

Oracle

Предоставляет оптимизированный доступ к базам данных Oracle (версии 8i и выше).

ODBC

Предоставляет доступ к любому источнику данных, имеющему драйвер ODBC.

В версии.NET 4 поставщик Oracle объявлен устаревшим. И хотя он по-прежнему работает, в Microsoft рекомендуют применять вместо него для доступа к базам данных Oracle поставщик от стороннего производителя, такой как ODP.NET (Oracle Data Provider для.NET) производства Oracle, который доступен на веб-сайте http://www.oracle.com . Этот поставщик обеспечивает расширенную поддержку для специализированных типов данных Oracle, вроде LOB, временных меток и данных XML, а также обладает несколькими дополнительными средствами.

На рисунке ниже показаны уровни модели поставщиков ADO.NET:

При выборе поставщика сначала пытайтесь найти встроенный поставщик.NET, который предназначен для имеющегося источника данных. Если таковой не найден, можно воспользоваться OLE DB при наличии драйвера OLE DB для источника данных.

Технология OLE DB существует уже много лет как часть ADO, поэтому для большинства источников данных предусмотрены драйверы OLE DB (включая SQL Server, Oracle, Access, MySQL и многие другие). В тех редких случаях, когда найти специализированный поставщик.NET или драйвер OLE DB не удается, можно обратиться к поставщику ODBC, который работает в сочетании с драйвером ODBC.

Стандартизация в ADO.NET

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

Но даже несмотря на то, что разные поставщики данных.NET используют различные классы, все они некоторым образом стандартизированы. Точнее говоря, каждый поставщик основан на одном и том же наборе интерфейсов и базовых классов. Так, например, объект Connection реализует интерфейс IDbConnection, который определяет такие ключевые методы, как Open() и Close(). Подобная стандартизация гарантирует, что каждый класс Connection будет работать одинаковым образом и предоставит один и тот же набор ключевых свойств и методов.

"За кулисами" различные поставщики используют совершенно разные низкоуровневые вызовы и API-интерфейсы. Например, поставщик данных SQL Server применяет патентованный протокол TDS (Tabular Data Stream - поток табличных данных) для взаимодействия с сервером. Преимущества этой модели не сразу очевидны, но весьма существенны:

    Поскольку каждый поставщик использует одни и те же интерфейсы и базовые классы, можно писать обобщенный код доступа к данным (с приложением небольших дополнительных усилий), работая с интерфейсами, а не классами поставщиков.

    Поскольку каждый поставщик реализован отдельно, он может использовать соответствующую оптимизацию (это отличается от модели ADO, где каждый вызов базы данных должен проходить через общий уровень, прежде чем достигнет лежащего в основе драйвера базы данных). Кроме того, специализированные поставщики могут добавлять нестандартные средства, которых не имеют другие поставщики (например, возможность SQL Sever выполнять XML-запросы).

ADO.NET также имеет другой уровень стандартизации - DataSet . Класс DataSet - это контейнер данных общего назначения, которые извлекаются из одной или более таблиц источника данных. DataSet полностью обобщен; другими словами, специализированные поставщики не определяют собственных специализированных версий класса DataSet.

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

Фундаментальные классы ADO.NET

Классы ADO.NET группируются в несколько пространств имен. Каждый поставщик имеет свое собственное пространство имен, а обобщенные классы вроде DataSet находятся в пространстве имен System.Data. Ниже описаны наиболее важные пространства имен для базовой поддержки ADO.NET:

System.Data

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

System.Data.Common

Содержит базовые, наиболее абстрактные классы, которые реализуют некоторые из интерфейсов из System.Data и определяют ядро функциональности ADO.NET. Поставщики данных наследуются от этих классов (DbConnection, DbCommand и т.п.), создавая собственные специализированные версии

System.Data.OleDb

Содержит классы, используемые для подключения к поставщику OLE DB, включая OleDbCommand, OleDbConnection и OleDbDataAdapter. Эти классы поддерживают большинство поставщиков OLE DB, но не те, что требуют интерфейсов OLE DB версии 2.5

System.Data.SqlClient

Содержит классы, используемые для подключения к базе данных Microsoft SQL Server, в том числе SqlDbCommand, SqlDbConnection и SqlDbDataAdapter. Эти классы оптимизированы для использования интерфейса TDS к SQL Server

System.Data.OracleClient

Содержит классы, необходимые для подключения к базе данных Oracle (версии 8.1.7 и выше), в том числе OracleCommand, OracleConnection и OracleDataAdapter. Эти классы используют оптимизированный интерфейс OCI (Oracle Call Interface - Интерфейс вызовов Oracle)

System.Data.Odbc

Содержит классы, необходимые для подключения к большинству драйверов ODBC, такие как OdbcCommand, OdbcConnection, OdbcDataReader и OdbcDataAdapter. Драйверы ODBC поставляются для всех видов источников данных и конфигурируются через значок Data Sources (Источники данных) панели управления

System.Data.SqlTypes

Содержит структуры, соответствующие встроенным типам данных SQL Server. Эти классы не являются необходимыми, но предоставляют альтернативу применению стандартных типов данных.NET, требующих автоматического преобразования