Разработка клиентских приложений на основе архитектуры «Клиент – сервер»

При разработке клиентских приложений архитектуры «клиент сервер» возникает задача обеспечения связи клиентских и серверных компонент приложения. Для решения этой задачи используется промежуточное программное обеспечение.

В промежуточном программном обеспечении можно выделить следующие составляющие.

Компоненты обеспечивающие ввод и отображение данных (средства создания интерфейса клиента)

Функции преобразования данных и команд клиента в команда СУБД. (API - Application ProgrammingInterface функции СУБД). Для каждой СУБД разрабатывается отдельная библиотека API функций.

Сетевые утилиты, преобразуют сетевые обращения к серверам БД в форму используемую в сетевых протоколах.

Существуют различные технологии реализации промежуточного программного обеспечения.

• В виде использования непосредственно API функций конкретной базы данных.

• Использование дополнительных библиотек соединения с данными (протокол ODBC. OLE DB)

• внедрение команд SQL непосредственно в программный код,

  • Использование технологии LINQU

• через использование специальных объектов компонент, предназначенных для связи с базой SQL.

Использования непосредственно API функций

Самый быстродейственный способ но самый сложный. Так как необходимо знать все тонкости использования API функций конкретного СУБД.

Пример взаимодействия с СУБД при помощи SQL аналога API-функции PHP

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

$link= mysql_connect(‘localhost’,’root’,’’);

2) Для пересылки инструкции SQL в СУБД программа формирует инструкцию в виде текстовой строки и затем передает эту строку в качестве параметра при вызове API-функции.

3) Программа вызывает API-функции для проверки состояния переданной в СУБД инструкции и для обработки ошибок.

4) Если инструкция SQL представляет собой запрос на выборку, то, вызывая API-функции, программа записывает результаты запроса в свои переменные; обычно за один вызов возвращается одна строка или один столбец данных.

5) Обращение к базе данных программа заканчивает вызовом API-функции, отключающей ее от СУБД.

Протокол ODBC.

Протокол ODBC (Open Database Connectivity — открытый доступ к базам данных), разработанный компанией Microsoft, предоставляет разработчикам приложений Windows универсальный программный интерфейс (API) доступа к практически любым базам данных. Единственное требование — это чтобы для данной базы данных существовал драйвер ODBC, "переводящий" использование стандартных функций ODBC в использование специфических функций конкретной СУБД. Практически все крупнейшие СУБД имеют драйвера ODBC. При вызове функций ODBC, инструкций SQL передаются в качестве аргументов этих функций. Таким образом, ODBC — это еще один вариант SQL API, не зависящий от конкретной СУБД. ODBC состоит из трех основных уровней:

1) Интерфейс вызовов функций. Набор стандартных функций, реализован в виде библиотеки DLL, который используется при написании программ.

2) Драйверы ODBC. Задачей драйвера является трансляция стандартных вызовов функций ODBC в вызовы соответствующих функций, поддерживаемых конкретной СУБД (их может быть и несколько для одной функции ODBC). Каждый драйвер устанавливается в операционной системе независимо. Это позволяет производителям СУБД разрабатывать для своих продуктов собственные драйверы и распространять их независимо от Microsoft.

3) Диспетчер драйверов. Отвечает за загрузку и выгрузку драйверов по запросам приложений, а также за направление вызовов функций ODBC, производимых приложениями, соответствующим драйверам для выполнения.

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

Технология OLE DB

ОLЕ DB – это технология, обеспечивает универсальный интерфейс для данных любого типа на основе технологии СОМ. Технология ОL DB позволяет производить доступ к звуковым данным, видеоданным, документам. Она может выступать как надстройка к ODBC/

В OLE DB включено несколько интерфейсов доступа к данным. Они организованы так, что работа компонентов доступа зависит от возможностей хранилища информации. Так как основана на СОМ, состав ее функций может быть расширен, добавив новые интерфейсы. Чтобы узнать, поддерживаются ли хранилищем какие-то специфические функции, клиенты могут воспользоваться стандартным методом Query Interface.

Возможность расширения функциональных возможностей — важное преимущество OLE DB перед ODBC.

На рис. проиллюстрирована высокоуровневая архитектура OLE DB, состоящая из трех основных элементов: потребителей данных, сервисных компонентов и компонентов доступа.

Потребители данных — это СОМ-компоненты, обращающиеся к информации с помощью компонентов доступа OLE DB.

Компоненты доступа OLE DB — это СОМ-компоненты, ответственные за передачу информации из хранилищ. Они представляют все данные в виде виртуальных таблиц, или наборов записей (rowset). Эти компоненты обращаются к хранилищу информации посредством его собственных методов доступа или же с помощью универсальных API, например, ODBC.

В сервисных компонентах реализована обработка запросов SQL.

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

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

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

Объектная модель ADO

СОМ-интерфейсы объектной модели OLE DB не совместимы с автоматизацией, и следовательно, OLE DB нельзя использовать напрямую во многих языках и средствах программирования, Поэтому определена еще одна программная модель уровня приложений — ADO.

Все интерфейсы ADO — двойные, поэтому их разрешено использовать в любом языке программирования, поддерживающем COM. ADO рекомендуется применять для доступа к хранилищам данных в многоуровневых приложениях Microsoft Windows DNA.

Объектная модель ADO основана на OLE DB, поэтому эти технологии очень похожи.

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

Доступ к данным с помощью ADO.NET

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

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

Отсоединенные объекты данных работают в режиме, напоминающем веб-сеансы. Все веб-сеансы являются обособленными, и их состояния не сохраняются между запросами веб-страниц. Отсоединенная архитектура данных позволяет осуществлять более «чистое» взаимодействие с базами данных в Сети.

Формы использования промежуточного программного обеспечения.

• Использование непосредственно API функций

• Внедрение команд SQL непосредственно в программный код

• Использование библиотек компонентов программных сред

Использование непосредственно API функций самый трудоёмкий способ, но обеспечивает лучшие возможности построения требуемой функциональности, интерфейса.

Внедрение в базовую программу подразумевает использование в программном коде высокоуровневого языка, например C++ , непосредственно команд SQL. Для этого среда программирования должна содержать специальный модуль «препроцессор», данный модуль преобразует блоки SQL в вызовы соответствующих API функций. Данная технология поддерживалась в среде Visual Studio 7.

Блоки SQL в программном коде ограничивались директивами exec SQL.

EXEC SQL BEGIN_DECLARE SECTION

….

EXEC SQL END DECLARE SECTION

Использование библиотек компонентов программных сред

Данный способ использования промежуточного обеспечения наиболее удобен для использования. Среда программирования предоставляет библиотеки функций промежуточного программного обеспечения в виде визуальных компонент. Отдельные среды программирования могут иметь несколько библиотек компонентов, поддерживающих различные технологии. Например Delphi Studio предоставляет компоненты, как на основе технологии Ole DB (ADO), так и на основе технологии ADO NET. Библиотеки компонентов на основе технологии ADO NET в настоящее время стали базовыми для построения приложений на остове хранилищь данных.

Реализация доступа к данным в среде Visual Studio 2005(8) на основе компонентов технологии ADO NET.

Технология ADO Net может обеспечивать построение архитектуры приложение как рассоединённой модели, так и соединенной.

При использовании рассоединённой модели обрабатываемые данные, предварительно копируются на сторону клиента, в специальный компонент DataSet. При использовании соединённой модели обрабатываемые данные остаются в исходном источнике, на сервере данных. Работа с данными при этом ведётся посредством вызова на стороне клиента команд, выполняемых на сервере.

Стандартной для ADO NET является рассоединённая модель.

При построении приложения на основе рассоединенной модели средствами Visual Studio 2005(8) создается трехзвенная объектная модель, включающая:

• Источник данных на стороне клиента (объект dataset);

• Объект обеспечивающий связь источника данных с отображаемым элементом - объект BindingSource;

• Объект, отображеющий данные на форме (DataGridView, TextBox, ListBox и т.д)

Рис. Иерархия компонентов, обеспечивающая связь с данными сервера.

Для связи управляющих элементов с данными, необходимо выполнить следующие действия.

• Открыть окно источников данных(DataSource) ;

Рис.2. Окно источников данных.

• создать в окне требуемые источники данных;

• установить для элементов созданных источников данных управляющие элементы требуемого типа;

• перетащить (Drag) требуемые источники данных на форму, при этом будут созданы соответствующие управляющие элементы.

Создание источника данных

Термин «Источник данных» в данном случае подразумевает источник на стороне клиента, из которого данные подаются в приложение.

При создании источника данных необходимо выбрать тип источника данных “Data Source type” .

Рис.3.. Выбор типа источника данных.

В данном случае возможны следующие источники данных:

• web service;

• база данных;

• объект данных, созданный в приложении.

Затем предлагается создать соединение с источником данных или выбрать созданное ранее соединение (созданные ранее соединения сохраняются). Параметры созданного соединения сохраняются в строке соединения “conectionString” .

Пример содержимого строки соединения

«Data Source=vann-pc;InitialCatalog=uch; Integrated Security=True».

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

Рис.4. Выбор объектов, включаемых в источник данных.

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

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

Рис.5. Выбор способа отображения элементов источников данных.

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

При перетаскивании элементов данных на форму создаются:

• источники данных на стороне клиента (DataSet), если это первый элемент из данного источника;

• управляющие элементы, отображающие данные на форме на форме (DataGtidView, TextBox и др.) ;

• специальные элементы, связывающие источники данных с отображаемыми элементами управления – BindingSource;

• элемент – TableAdapter, выполняющий связь данных на стороне клиента с данными в исходном источнике хранения (базе данных).

Связь этих элементов реализуется следующим образом

У элемента DataGridView в качестве значения свойства DataSource задается имя некоторого элемента BindingSource.

У данного элемента BindingSource, в качестве значения свойтва DataSource задается имя DataSet, таблица которого отображается, имя отображаемой таблицы, задается в значении свойства DataMember.

По существу элемент BindingSource передает таблицу из DataSet в некоторый отображаемый объект.