>

Технология ado net. Технологии ADO.NET. Автономные классы и объекты

Тем, кто пишет запросы в коде страницы посвящается...

Приветствую всех!

На хабре есть немного информации о том, что в следующей версии VisualStudio 2008 будет ADO.NET EntityFramework. (Открою секрет, эта версия уже появилась.) Эта разработка представляет собой универсальный фреймворк, который позволяет создавать даталогику вашего проекта в пару кликов мыши.
До сих пор, работая с даталогикой, я сталкивался с 2 видами проектов. Первые были созданы на небезызвестном фреймворке NHibernate , другие реализовывали даталогику программистами. Я уже 3 года занимаюсь написанием и разработкой различных систем и всё это время разрабатывал логику работы с данными исключительно ручками.
И вот, на днях, после того, как я поставил новую винду, я скачал VisualStudio WebDeveloper Express, и с радостью обнаружил в комплекте поставки ADO.NET EntityFramework. Через некоторое время зарегистрировал домен, создал простенький сайт, и начал тренировать свои силы в написании программ под этот фреймворк.

Для начала необходимо создать простой Web проект с базой данных. К базе данных тоже неплохо было бы подключится сразу через DataBase Explorer. Просто потом будет удобнее.

После этого, в проект надо добавить новый элемент «ADO.NET Entity Data Model».

Системе надо будет указать строку для соединения с базой, а так же указать, откуда возьмётся первая модель ADO.NET EF.

В своей БД я уже имею две очень простых таблицы Post и User, поэтому не мудрствуя лукаво, я заставил систему создать модель на основе моей БД. После всех этих, очень простых действий, я получил рабочую модель БД. Более того, изучив эту модель визуально, я не забыл заглянуть в код, и посмотреть, как же фрейворк описывает все мои классы?

  1. namespace DataBaseCore
  2. ///
  3. /// There are no comments for DbModel in the schema.
  4. ///
  5. public partial class DbModel: global::System.Data.Objects.ObjectContext
  6. ///
  7. /// Initializes a new DbModel object using the connection string found in the "DbModel" section of the application configuration file.
  8. ///
  9. public DbModel() :
  10. base ("name=DbModel" , "DbModel" )
  11. this .OnContextCreated();
  12. /* Урезал за ненадобностью */
  16. public partial class Post: global::System.Data.Objects.DataClasses.EntityObject
  17. ///
  18. /// Create a new Post object.
  19. ///
  20. /// Initial value of Id.
  21. public static Post CreatePost(int id)
  22. Post post = new Post();
  23. post.Id = id;
  24. return post;

Намётанный глаз специалиста по работе с даталогикой показал наличие достаточно простого и изящного класса, который позволил работать как с постами в системе, так и с пользователями.

Ну, что же, код у нас уже есть, осталось только его начать использовать. И тут, нам открываются все прелести и возможности ASP.NET. Среди немалого количества источников данных на странице я увидел Entity Data Source, который с удовольствием предоставляет данные по запросу из нашего класса. Перетаскиваем его на форму, запускаем мастер настройки, и быстренько цепляем датасорс на нашу таблицу постов.

Несомненно, намного приятнее стало выглядеть описание датасорца в ASPX коде.

  1. < asp:EntityDataSource ID ="dsPosts" runat ="server" ConnectionString ="name=DbModel"
  2. DefaultContainerName ="DbModel" EntitySetName ="Post" >
* This source code was highlighted with Source Code Highlighter .

Можно сказать - блещет изяществом.

После появления на форме провайдера данных, нужен и потребитель. Не умничая, я добавил простенький код, который просто отображает все посты последовательно.

  1. < asp:Repeater runat ="server" ID ="repPosts" DataSourceID ="dsPosts" >
  2. < HeaderTemplate >
  4. < ItemTemplate >
  5. < div >
  6. < h3 >
  7. < asp:Label ID ="lblHeader" runat ="server" Text ="<%# Eval("Header") %>" >
  9. < p >
  10. < asp:Label ID ="lblText" runat ="server" Text ="<%# Helpers.TypographText(Eval("Text").ToString()) %>" >
* This source code was highlighted with Source Code Highlighter .

И вот тут заканчивается самая простая часть моего повествования. До сих пор, всё что было сделано, можно повторить при помощи мыши. Это было достаточно просто. Мы только что создали объектно-ориентированное представления БД, и используя это представление, начали выводить данные из базы на страницу. При этом, мы ни разу не написали ни одного запроса, не получали данные из базы напрямую, etc…

Но, что же выводить пользователю, если у нас нет ничего в БД? Нехорошо. Надо написать форму заполнения базы. Теперь мы бросим мышепрограммирование, и займёмся написанием кода.

Я сделал два самых базовых действия для работы с постами в системе - это добавление и удаление. Сделать редактирование по аналогии с этим кодом не составит труда ни для кого.

  1. namespace DBW
  2. public class Post
  3. public Post()
  4. public static void New(String PostText, String PostHeader, Int32 UserId)
  5. p.Header = PostHeader;
  6. p.Text = Helpers.TypographText(PostText);
  7. p.PublishDate = DateTime .Now;
  8. p.User = (from usr in m.User where usr.Id == UserId select usr).First();
  9. m.AddToPost(p);
  10. m.SaveChanges();
  11. public static void Delete(Int32 PostId)
  12. DataBaseCore.DbModel m = new DataBaseCore.DbModel();
  13. DataBaseCore.Post p = new DataBaseCore.Post();
  14. p = (from pst in m.Post where pst.Id == PostId select pst).First();
  15. m.DeleteObject(p);
  16. m.SaveChanges();
* This source code was highlighted with Source Code Highlighter .

Казалось бы, всё просто, и да, это так. Но есть пара нюансов.
Во-первых - это LINQ. Без него в ADO.NET никуда. Так что не стоит отлынивать и вообще забивать на SQL или LINQ, писать запросы всё равно придётся.
Во-вторых - этот код автоматически генерируется фреймворком, поэтому особого удобства в некоторых моментах ожидать не придётся, и всегда надо быть готовым изменить уже созданный студией код. Например, тут в строке 16 было бы удобнее использовать не объект типа пользователь, который мне пришлось выбирать из БД, а сразу передавать значение идентификатора пользователя. Так было бы удобнее для этого кода, но это не универсально. Поэтому код нуждается в доработке и переосмыслении. Возможно просто надо передавать не идентификатор пользователя, а объект типа пользователь.

Что дальше? Дальше я буду продолжать писать проект, углубляясь в дебри ADO.NET Entity Framework, и буду с удовольствием делиться своими изысканиями с вами, уважаемые хабраюзеры. Соответственно, будут новые статьи, с более серьёзными и глубокими данными.

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

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

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

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

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

Последнее обновление: 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, . 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 с помощью соответствующего объекта адаптера данных подключение открывается и закрывается автоматически. Понятно, что этот подход помогает быстро освобождать подключения для других вызовов и повышает масштабируемость систем.