Коротко на вопрос «Что такое ADO?» можно ответить так: это основная технология доступа к данным, не только реляционные базы данных для платформы.NET. Более конкретно — это набор объектов, при помощи которых программист может осуществить подключение к серверу баз данных, выборку данных и/или их модификацию.
Многие программисты, работающие с базами данных на платформах Microsoft, могли оценить простоту и удобство технологии ADO — ActiveX Data Objects. Интуитивно-понятный интерфейс и логичный набор объектов вместе с простотой программирования заслуженно получили признание программистов. Несмотря на это, вместе с новой платформой.NET Microsoft представляет и новое поколение средств доступа к базам данных — ADO.NET. Cтремительное развитие веб приложений вызвало необходимость пересмотреть методы работы с источниками данных, лучше адаптировать их к специфики приложений. Непредсказуемый рост числа клиентов интернет сайтов заставляет разработчиков переходить от клиентсерверной к three-tier архитектуре, что часто порождает непреодолимые проблемы. Базы данных не способны поддерживать неограниченное число активных соединений, ограничивая доступность сайта и принося убытки. Брандмауэры могут препятствовать передаче двоичных данных между узлами. ADO.NET призвано решить эти и другие проблемы и вместе с тем сохранить удобство и простоту программирования.
ADO была разработана для архитектуры клиент-сервер. Эта архитектура в течение ряда лет была достаточно прогрессивной, если учесть, что пришла она на смену архитектуре файл-сервер. Потом все нарастающая сложность систем обработки данных потребовала качественного изменения архитектуры: кроме двух уровней клиент и сервер баз данных появляются дополнительные уровни серверы, реализующие бизнес-логику приложений. До сих пор, правда, ни одна из разработанных для этой цели архитектур (в частности, DCOM и CORBA) не добились впечатляющих успехов в этом направлении, и на сегодняшний момент мне известно, пожалуй, больше вирусов, использующих их слабости, чем реально работающих продуктов на их основе..NET в целом и ADO.NET в частности очередная попытка навести порядок в сегменте многоуровневых приложений и сделать их разработку относительно простым и приятным занятием. Что из этого выйдет, судить пока рано, но, на мой взгляд, перспективы неплохи [1].
Поскольку ADO.NET ориентирована на разработку многоуровневых приложений корпоративного масштаба, это отложило неизбежный отпечаток на способы взаимодействия клиента с сервером. Если основной сценарий работы клиента в ADO начинается с создания соединения, которое потом удерживается открытым весь сеанс, то ADO.NET гораздо самостоятельнее в этом отношении. Вполне допустимым является сценарий, когда клиент устанавливает соединение, получает необходимые данные, закрывает соединение, длительное время обрабатывает данные, после чего вновь устанавливает соединение для передачи измененных данных обратно на сервер.
Искушенные в ADO программисты могут возразить, что, мол, мы уже давно имели такую возможность в виде отсоединенных наборов записей. Да, частично они правы. Однако отсоединенные наборы записей стоят несколько особняком в объектной модели ADO, и их функциональность оставляет желать лучшего.
MSDN божится, что при разработке ADO.NET преследовалась цель сделать новую платформу как можно более совместимой с прежней, так что разработчики особой разницы не заметят.
Преимущества и нововведения в ADO.NET. Использование разъединенной модели доступа к данным. В клиент-серверных приложениях традиционно используется технология доступа к источнику данных при которой соединение с базой поддерживается постоянно. Однако после широкого распространения приложений, ориентированных на Интернет, выявились некоторые недостатки такого подхода. Попробуем выявить некоторые из них. Соединения с базой данных требуют выделения системных ресурсов, что может быть критично при большой нагрузке сервера. Хотя постоянное соединение позволяет несколько ускорить работу приложения, общий убыток от растраты системных ресурсов сводит преимущество на нет.
Специфика веб приложений не позволяет серверу в каждый момент времени знать, что необходимо пользователю. То есть до следующего запроса сервер не имеет представления, нужно ли еще поддерживать соединение.
Опыт разработчиков показал, что приложения с постоянным соединением с источником данных чрезвычайно трудно поддаются масштабированию.
Хотя существуют и другие недостатки, приведенные, на мой взгляд, наиболее существенны и вероятнее всего встречались читателю. Все эти проблемы порождаются постоянным соединением с базой данных и решаются в ADO.NET, где используется другая модель доступа. Теперь соединение устанавливается лишь на то короткое время, когда необходимо проводить операции над базой данных.
Следует признать, что новая технология иногда все же проигрывает традиционной. Для этих случаев рекомендовано (не только мною, но и Microsoft) использовать ADO.
Хранение данных в объектах DataSet. При работе с базой данных нам чаще всего приходится работать не с одной, а несколькими записями. Более того, данные эти могут собираться из различных таблиц. В разъединенной модели доступа к базе данных не имеет смысла соединяться и источником данных при каждом обращении. Исходя из этого, представляется логичным хранить несколько строк и обращаться к ним при необходимости. Для этих целей и используется DataSet [2].
DataSet представляет собой, по сути, упрощенную реляционную базу данных и может выполнять наиболее типичные для таких баз данных операции. Теперь, в отличие от Recordset мы можем хранить в одном DataSet сразу несколько таблиц, связи между ними, выполнять операции выборки, удаления и обновления данных. Безусловно, разъединенная модель не позволяет постоянно отслеживать изменения в базе данных, производимые другими пользователями. Это может привести к ошибкам в таких приложениях, где информация должна обновляться каждый момент — заказ билетов или продажа ценных бумаг. Однако в любую секунду может быть получена свежая информация из базы данных через вызов метода FillDataSet. Таким образом, DataSet остается чрезвычайно удобным для самого широкого класса приложений: когда необходимо получить данные из базы и как-либо обработать их.
ADO.NET поддерживает два типа источников данных — SQL Managed Provider и ADO Managed Provider. SQL Managed Provider применяется для работы с Microsoft SQL Server 7.0 и выше, ADO Managed Provider — для всех остальных баз данных.
SQL Managed Provider — работает по специальному протоколу, называемому TabularData Stream (TDS) и не использует ни ADO, ни ODBC, ни какую-либо еще технологию. Ориентированный специально на MS SQL Server, протокол позволяет увеличить скорость передачи данных и тем самым повысить общую производительность приложения.
ADO Managed Provider — предназначен для работы с произвольной базой данных. Однако за счет универсальности есть проигрыш по сравнению с SQL Server Provider, так что при работе с SQL Server рекомендовано использовать специализированные классы. В данном обзоре мы коснемся ADO Managed Provider лишь мельком, указав только существующие незначительные различия, так как наиболее употребимой базой данных представляется SQL Server 7.0 или 2000, а разница заключается, в основном, в именовании.
Объекты DataSet ADO.NET. Объект DataSet является центральным элементом поддержки разъединенных распределенных сценариев данных в ADO.NET. Объект DataSet является находящимся в оперативной памяти представлением данных, обеспечивающим согласованную реляционную программную модель, независимо от источника данных. Он может использоваться с несколькими различными источниками данных, XML-данными или для управления данными, локальными по отношению к приложению. Объект DataSet представляет полный набор данных, включая связанные таблицы, ограничения и связи между таблицами. На следующей иллюстрации показана модель объектов DataSet.
ADO.NET DataSet — расположенное в оперативной памяти представление данных, обеспечивающее согласованную реляционную программную модель независимо от источника данных. DataSet представляет полный набор данных, включая таблицы, содержащие, упорядочивающие и ограничивающие данные, а также связи между таблицами.
Существует несколько способов работы с DataSet, которые могут применяться отдельно или в сочетании. Можно выполнить следующие действия:
- Программно создать DataTable, DataRelation и Constraint внутри DataSet и заполнить таблицы данными.
- Заполнить DataSet таблицами данных из существующего реляционного источника данных с помощью DataAdapter.
- Загрузить и сохранить содержимое DataSet с помощью XML-кода.
Строго типизированный DataSet также можно передавать с помощью веб-службы с поддержкой XML-кода. Конструкция DataSet делает его идеальным для передачи данных с помощью веб-служб с поддержкой XML-кода.
Объектная модель DataSet. Методы и объекты DataSet согласованы с методами и объектами модели реляционной базы данных.
Объект DataSet также может сохранять и повторно загружать свое содержимое в виде XML, а свою схему — в виде схемы XSD.
Класс DataTableCollection. Объект ADO.NET DataSet содержит коллекцию, содержащую ноль или более таблиц, представленных объектами DataTable. Коллекция DataTableCollection содержит все объекты DataTable в объекте DataSet.
Объект DataTable определяется в пространстве имен System.Data и представляет собой одну таблицу, находящуюся в оперативной памяти. Он содержит коллекцию столбцов, представленных объектом DataColumnCollection, и ограничений, представленных объектом ConstraintCollection, которые вместе определяют схему таблицы. Объект DataTable также содержит коллекцию строк, представленных объектом DataRowCollection, содержащим данные в таблице. Вместе со своим текущим состоянием объект DataRow сохраняет обе свои версии (текущую и исходную), чтобы определить изменения значений, хранимых в строке.
Класс DataView. DataView позволяет создавать различные представления данных, которые хранятся в DataTable. Эта возможность часто используется в приложениях связывания данных. С помощью объекта DataView можно представлять данные в таблице с различными порядками сортировки, а также фильтровать данные по состоянию строки или на основе критерия фильтра.
Класс DataRelationCollection .Объект DataSet содержит связи в своем объекте DataRelationCollection. Связь, представленная объектом DataRelation, связывает строки в одном объекте DataTable со строками в другом объекте DataTable. Связь аналогична пути соединения, который может существовать между столбцами первичного и внешнего ключей реляционной базы данных. Объект DataRelation определяет совпадающие столбцы в двух таблицах объекта DataSet.
Связи позволяют перемещаться в объекте DataSet от одной таблицы к другой. Важными элементами объекта DataRelation являются имя связи, имена связанных таблиц и связанные столбцы в каждой таблице. Связи могут быть построены с более чем одним столбцом для каждой таблицы путем указания массива объектов DataColumn в качестве ключевых столбцов. При добавлении связи к объекту DataRelationCollection дополнительно можно добавить UniqueKeyConstraint и ForeignKeyConstraint, чтобы обеспечить ограничения целостности в случае изменений значений связанных столбцов.
Подведем итог. ADO.NET представляет новую структуру объектов и новую модель доступа к данным, позволяющую улучшить производительность наиболее часто встречающихся приложений. Это дает нам основания пророчить ADO.NET как основную технологию доступа данным в веб приложениях.
Литература:
1. Сеппа Д. Microsoft ADO.NET. /Пер. с англ. — М.: Издательско-торговый дом «Русская Редакция», 2003- — 640 стр.
2. Альманах программиста, том I: Microsoft ADO.NET, Microsoft SQL Server, доступ к данным из приложений. /Сост. Ю. Е. Купцевич. — М.: Издательско-торговый дом «Русская Редакция», 2003. — 400 с.
