Справочник функций

Ваш аккаунт

Войти через: 
Забыли пароль?
Регистрация
Информацию о новых материалах можно получать и без регистрации:

Последние темы форума

Показать новые сообщения »
реклама
Интересные обзоры о казино на сайте:kasinoguru.info.

Почтовая рассылка

Подписчиков: 11869
Последний выпуск: 19.06.2015

ADO.NET

Автор: Ветров Павел Владимирович
Тюменский Государственный Университет
Институт математики и компьютерных наук

Введение.

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

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

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

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

Цели и задачи

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

ADO.NET

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

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


Рис. 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 в полной мере способна предоставить механизм для доступа к любому источнику данных, тем самым, предоставляя разработчику мощный механизм взаимодействия с базами данных способный в полной мере реализовать все потребности, возникающие при проектировании ИС.

Оставить комментарий

Комментарий:
можно использовать BB-коды
Максимальная длина комментария - 4000 символов.
 

Комментарии

1.
18K
04 июля 2006 года
dethonator
2 / / 04.07.2006
+1 / -0
Мне нравитсяМне не нравится
6 марта 2008, 05:52:57
Вполне адекватная статья. И впринципе все понятно! ADO.NET - предоставляет унифицированный интерфейс для доступа к данным, которые в свою очередь должны иметь на борту управляемый провайдер - это основная идея, и в статье она очень четко прослеживается.
2.
245
26 июля 2006 года
Комаджу
850 / / 26.07.2006
+2 / -0
Мне нравитсяМне не нравится
31 октября 2007, 19:32:26
Судя по комментарию, Cybister совершенно не понял, что такое ADO.NET. Более того, судя по его "взгляду в прошлое" кругозор у него не просто узкий.
3.
33K
29 октября 2007 года
Cybister
0 / / 29.10.2007
+0 / -1
Мне нравитсяМне не нравится
29 октября 2007, 16:15:09
Всё замечательно, только вот интересно кто из тех то ваяет на .NET будет юзать что-то кроме MSSQL (зачастую в силу довольно узкого кругозора). И к слову есть библиотека ADODB для PHP, которая если не ошибаюсь уже существовала когда .NET был ещё 1.0b.
Реклама на сайте | Обмен ссылками | Ссылки | Экспорт (RSS) | Контакты
Добавить статью | Добавить исходник | Добавить хостинг-провайдера | Добавить сайт в каталог