ADO.NET. Элементы теории — C# ~ Си шарп для начинающих

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

Модели «клиент-сервер» в технологии баз данных

Вычислительная модель «клиент—сервер» исходно связана с парадигмой открытых систем, которая появилась в 90-х годах и быстро эволюционировала. Сам термин «клиент—сервер» исходно применялся к архитектуре программного обеспечения, которое описывало распределение процесса выполнения по принципу взаимодействия двух программных процессов, один из которых в этой модели назывался «клиентом», а другой — «сервером». Клиентский процесс запрашивал некоторые услуги, а серверный процесс обеспечивал их выполнение. При этом предполагалось, что один серверный процесс может обслужить множество клиентских процессов.

Основной принцип технологии «клиент—сервер» применительно к технологии баз данных заключается в разделении функций стандартного интерактивного приложения на 5 групп, имеющих различную природу:

функции ввода и отображения данных (Presentation Logic);
прикладные функции, определяющие основные алгоритмы решения задач приложения (Business Logic);
функции обработки данных внутри приложения (Database Logic);
функции управления информационными ресурсами (Database Manager System);
служебные функции, играющие роль связок между функциями первых четырех групп.

Двухуровневые модели

Двухуровневые модели фактически являются результатом распределения пяти указанных функций между двумя процессами, которые выполняются на двух платформах: на клиенте и на сервере. В чистом виде почти никакая модель не существует, однако рассмотрим наиболее характерные особенности каждой двухуровневой модели.
1) Модель удаленного управления данными. Модель файлового сервера (File Server). В этой модели презентационная логика и бизнес-логика располагаются на клиенте. На сервере располагаются файлы с данными и поддерживается доступ к файлам. Функции управления информационными ресурсами в этой модели находятся на клиенте.
2) Модель удаленного доступа к данным (Remote Data Access). В ней база данных хранится на сервере. На сервере же находится ядро СУБД. На клиенте располагается презентационная логика и бизнес-логика приложения. Клиент обращается к серверу с запросами, например, на языке SQL.
3) Модель сервера баз данных. В этой модели бизнес-логика разделена между клиентом и сервером. На сервере бизнес-логика реализована в виде хранимых процедур — специальных программных модулей, которые хранятся в БД и управляются непосредственно СУБД. Клиентское приложение обращается к серверу с командой запуска хранимой процедуры, а сервер выполняет эту процедуру и регистрирует все изменения в БД, которые в ней предусмотрены. Сервер возвращает клиенту данные, релевантные его запросу, которые требуются клиенту либо для вывода на экран, либо для выполнения части бизнес-логики, которая расположена на клиенте. Трафик обмена информацией между клиентом и сервером резко уменьшается. Централизованный контроль в модели сервера баз данных выполняется с использованием механизма триггеров. Триггеры также являются частью БД.

Трехуровневая модель сервера приложений

Эта модель является расширением двухуровневой модели и в ней вводится дополнительный промежуточный уровень между клиентом и сервером. Этот промежуточный уровень содержит один или несколько серверов приложений. В этой модели компоненты приложения делятся между тремя исполнителями:
1) Клиент обеспечивает логику представления, включая графический пользовательский интерфейс, локальные редакторы; клиент может запускать локальный код приложения клиента, который может содержать обращения к локальной БД, расположенной на компьютере-клиенте. Клиент исполняет коммуникационные функции front-end части приложения, которые обеспечивают доступ клиенту в локальную или глобальную сеть. Дополнительно реализация взаимодействия между клиентом и сервером может включать в себя управление распределенными транзакциями.
2) Серверы приложений составляют новый промежуточный уровень архитектуры. Они спроектированы как для исполнения общих незагружаемых функций клиентов. Серверы приложений поддерживают функции клиентов как частей взаимодействующих рабочих групп, поддерживают сетевую доменную операционную среду, хранят и исполняют наиболее общие правила бизнес-логики, поддерживают каталоги с данными, обеспечивают обмен сообщениями и поддержку запросов, особенно в распределенных транзакциях.
3) Серверы баз данных в этой модели занимаются исключительно функциями СУБД: обеспечивают функции создания и ведения БД, поддерживают целостность реляционной БД, обеспечивают функции хранилищ данных (Warehouse services). Кроме того, на них возлагаются функции создания резервных копий БД и восстановления БД после сбоев и управления выполнением транзакций.

Отметим, что эта модель обладает большей гибкостью, чем двухуровневые модели. Наиболее заметны преимущества модели сервера приложений в тех случаях, когда клиенты выполняют сложные аналитические расчеты над базой данных, которые относятся к области OLAP-приложений (On-line analytical processing). В этой модели большая часть бизнес-логики клиента изолирована от возможностей встроенного SQL, реализованного в конкретной СУБД, и может быть выполнена на стандартных языках программирования. Это повышает переносимость системы и ее масштабируемость.

Архитектура ADO.NET

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

Платформа .NET определяет ряд пространств имен, позволяющих непосредственно взаимодействовать с локальными и удаленными базами данных (БД). Вместе они известны как ADO.NET.

Мы рассмотрим два уровня работы с ADO.NET:
подключенный уровень (connected layer) — позволяет взаимодействовать с базой данных с помощью объектов подключения, чтения данных и команд конкретного поставщика данных;
отключенный уровень (disconnected layer) — позволяет смоделировать в оперативной памяти данные из базы данных с помощью многочисленных классов из пространства имен System.Data (DataSet, DataTable и т.д.)
Существует и третья возможность взаимодействия с базами данных через объектную модель C#, с помощью ORM-фреймворка Entity Framework 4.0, которую мы пока рассматривать не будем.

Пространство имен System.Data

ADO.NET поставляется с тремя пространствами имен клиента базы данных: одно для SQL Server; второе — для любой базы данных, доступной через OLE DB; третье — для источников данных Open Database Connectivity (ODBC) . Если выбрана база данных, отличная от SQL Server, то отдают предпочтение OLE DB, если только не окажется, что нет другого выбора кроме ODBC. Если же в качестве базы данных используется Oracle, то на сайте Oracle .NET Developer можно получить их поставщика .NET — ODP.NET.

С точки зрения программиста, тело ADO.NET составляет базовая сборка с именем System.Data.dll. В этом двоичном файле находятся пространства имен, которые представляют типы конкретного поставщика данных ADO.NET, это: Odbs { }, OleDb { }, SqlClient { }, и кроме того: Common { }, Sql { }, SqlTypes { } и другие.
Большинство шаблонов проектов Visual Studio автоматически ссылаются на эту ключевую библиотеку System.Data { } доступа к данным. Однако для импорта нужных пространств имен необходимо изменить кодовые файлы, например:

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 для доступа к данным и их обработки являются поставщики данных .NET Framework и DataSet.

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

— это компоненты, которые специально сконструированы для обработки данных и быстрого, однопроходного доступа к данным только для чтения:

Объект Connection обеспечивает подключение к источнику данных.
Объект Command позволяет обращаться к командам базы данных для возврата данных, изменения данных, выполнения хранимых процедур и передачи или получения сведений о параметрах.
DataReader обеспечивает высокопроизводительный поток данных из источника данных.
DataAdapter предоставляет «мост» между объектом DataSet и источником данных. DataAdapter использует объекты Command для выполнения команд SQL на источнике данных для загрузки DataSet с данными и согласования изменений данных, выполненных в DataSet, вновь с источником данных.
Parameter представляет именованный параметр в параметризованном запросе.
Transaction инкапсулирует транзакцию в базе данных.

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

Класс DataSet в ADO.NET

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

Пример «Продажа билетов в кинотеатре» демонстрирует способ работы с источником данных в автономном режиме. При получении DataSet с помощью объекта — адаптера данных кино1TableAdapter подключение открывается и закрывается автоматически (метод кино1TableAdapter.Fill(this.kinoDataSet.кино1);). Визуальный компонент dataGridView1 отображает содержимое kinoDataSet через связующий компонент кино1BindingSource. Получив объект DataSet, программа может просматривать и обрабатывать данные без затрат на сетевой трафик. А если нужно занести изменения в хранилище данных, то адаптер данных (метод кино1TableAdapter.Update(this.kinoDataSet.кино1);) выполняет действия по обновлению данных — при этом подключение открывается заново для проведения обновлений в базе, после чего сразу же закрывается. Легко представить себе регламент работы нескольких кассиров с одной базой данных — после ввода информации о проданных билетах достаточно лишь нажать кнопку «Обновить». Промоделируйте работу нескольких кассиров с одной базой данных в своей локальной сети.

NEW: Наш Чат, в котором вы можете обсудить любые вопросы, идеи, поделиться опытом или связаться с администраторами.