2.3.1 Реализация взаимодействия между сервером приложений и сервером баз данных

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

Механизм загрузки данных реализован таким образом, чтобы минимизировать время открытого соединения с базой данных и объем передаваемых данных. В ходе проектирования было решено отказаться от использования стандартных классов DataSet и TableAdapter ввиду того что в большинстве случаев на определенной странице приложения используются лишь некоторые из таблиц БД. Соответственно нет смысла хранить на каждой странице приложения коллекции таблиц БД. Отказавшись от такого подхода можно увеличить быстродействие и сократить объем страниц, повысив при этом трудоемкость разработки [8].

Также для минимизации трафика между базой данных и приложением все запросы, выполнение которых возможно на стороне базы данных выполняются на ней. Например, запросы с использованием соединений таблиц могут быть реализованы двумя способами:

1. Загрузка массивов данных на сторону сервера приложений и реализация логики создания временных структур данных посредством алгоритмов приложения.

2. Отправка на сервер базы данных готовых SQL-запросов, выполнение которых будет вестись на стороне сервера баз данных, а приложение получит в ответ набор кортежей, являющихся результатом выполнения запроса.

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

Работа с данными осуществляется с использованием следующих классов:

– SqlConnection. Используется для открытия безопасного подключения к базе данных;

– SqlCommand. Используется для отправления управляющих инструкций для СУБД в форме SQL-запросов;

– SqlDataReader. Используется для потокового чтения данных из базы;

– DataTable. Используется для хранения табличных структур данных на стороне приложения.

Общее представление алгоритмов выборки и модификации данных отражено на рисунке 2.2. Различие алгоритмов лишь в том, что для алгоритмов выборки в приложение направляется поток данных - результатов выборки, а для управляющих команд только подтверждение их выполнения [9].

При этом выполнения всех операций с удаленными данными осуществляется в пределах инструкции try..catch для повышения стабильности работы приложения и корректной обработки возникающих ошибок. К примеру временная недоступность базы данных из-за неполадок в канале связи не вызовет крах приложения.

Рисунок 2.2 - Обобщенный алгоритм обмена данными СУБД

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

При одновременной работе множества распределенных клиентов с приложением возможны конфликтные ситуации в обработке запросов к базе данных. Благодаря внутреннему механизму блокировок SQL Server такие конфликты урегулируются автоматически за счет временного ограничения доступа к модифицируемым данным.

2.3.2 Реализация клиент-серверного взаимодействия

Вся бизнес-логика приложения сосредоточена в серверном коде и «тонкий» клиент получает готовые html-страницы с активными элементами управления. Благодаря такому подходу веб-приложению безразличны детали реализации клиентских приложений (браузеров) [10].

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

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

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

Рисунок 2.3 - Просмотр кода страницы приложения в браузере

2.3.3 Разработка страниц ориентированных на клиентов

Из десяти страниц приложения шесть являются клиент-ориентированными: default.aspx, catalog.aspx, order.aspx, about.aspx, manufacturer.aspx, showpdf.aspx.

Все они являются контентными для базового MasterPage и реализуют функционал приложения, направленный на обеспечение функционирования системы приема заявок и популяризацию фирмы.

Особенностью всех клиент-ориентированных страниц является забота о защите приложения от непреднамеренной и преднамеренной порчи, или кражи информации. В рамках такой политики была реализована защита от SQL-инъекций посредством замены всех запросов к базе данных на параметризованные. Такой подход лишает механизм выполнения запросов некоторой гибкости, но не позволит злоумышленнику внедрить вредоносный код в запрос [11].

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

Ключевым управляющим элементом каталога является полнофункциональное дерево категорий. Запасные части сгруппированы в дерево категорий, динамически выстраиваемое в виде элемента TreeView на основе данных таблицы categories, в которой хранятся узлы дерева
с указанием родительских узлов. Построение древа реализуется функцией
BuildTree(DataTable ToBuild), которая также обеспечивает корректное именование узлов, отображающее пользователю понятные названия категорий, сохраняя значения кодов категорий. Таким образом, после построения дерева таблица его образующая удаляется при перезагрузке страницы и уже не запрашивается из базы, что существенно сокращает последующее время загрузок страницы при активной работе, в то время как состояние элемента управления сохраняется в переменной состояния ViewState [12].

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

Еще одной важной задачей являлось создание активного списка товара принадлежащего выбранной категории. Поскольку элемент управления GridView напрямую не поддерживает обработку нажатий на строки таблицы и не вызывает отправку страницы на сервер было решено переопределять все строки таблицы при их создании. Для этого был перегружен обработчик события OnRowDataBound, добавляющий на строки таблицы Java-скрипты, исполняемые на стороне клиента. С их помощью стало возможным отслеживание кликов по строчкам таблицы и изменение стиля при наведения курсора на ячейки без использования специальных управляющих кнопок в дополнительных столбцах GridView. При выборе какой-либо позиции управление передается серверу с указанием позиции. Активная таблица товаров отражена на рисунке 2.4.

Рисунок 2.4 - Управляемая скриптами таблица товара

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

Разработка страницы оформления заказа. Данная страница инкапсулирует в себе логику оформления заказов и реализует функции модификации списка товаров, а также деталей заказа. Кроме того на нее возложены функции проверки корректности составления заказа перед изменением статуса продвижения на «отправленный».

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

Для предоставления потенциальным клиентам инструментария редактирования товаров заказа потребовалось также переопределять набор строк табличного элемента управления. Ячейки столбца, содержащего количество товара, потребовалось динамически заменять во время компиляции страницы на текстовые поля TextBox с серверными идентификаторами для последующего обхода при изменении количества оформляемого на продажу товара. Аналогичным способом добавлен столбец кнопок, предназначенных для удаления товаром из корзины. Преимуществом такого подхода является полная независимость от коллекции столбцов таблицы, подключаемой в GridView. Управляемый список товаров в корзине представлен на рисунке 2.5.

Рисунок 2.5 - Список товара с интегрированными элементами управления

2.3.4 Разработка страниц, организующих управление содержимым сайта

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

Регулирование доступа к содержимому возложено на вложенный MasterPage, автоматически сохраняющий свое состояние на время работы с страницами администратора. Система доступа построена таким образом, что у веб-приложения используется одна запись администратора, пароль к которой хранится в таблице серверных переменных и даже подделав, или подменив запрос злоумышленнику не удастся получить пароль администратора. Защищенный паролем контент не высылается в браузер клиента до тех пор, пока не будет активирован [13].

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

2.3.5 Разработка модуля подготовки отчетов

Модуль подготовки отчетов используется для формирования документов в формате PDF с использованием свободно распространяемой библиотеки iTextSharp.dll. Данное расширение предоставляет программисту наборы структур данных, механизмов их заполнения и вывода в документы. Необходимые описания классов, методов и структур данных находятся в заголовочных файлах iTextSharp.text; iTextSharp.text.pdf; iTextSharp.text.html.simpleparser.

Сам модуль базируется на странице showpdf.aspx, однако эта страница никогда демонстрируется пользователю. Вместо этого на страницу методом открытого GET-запроса передается код заказа, который необходимо вывести в документ.

При загрузке страницы этот параметр анализируется, из базы данных подгружается необходимая информация и выводится в документ в два этапа:

1. Выводится описательная информация, прилагаемая к заказу.

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

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

Особенностью использования библиотеки iTextSharp.dll является отсутствие поддержки кириллических шрифтов. Для решения этой проблемы потребовалось импортировать на сервер в диспетчер шрифтов готовый файл шрифта Arial со встроенными расширениями для кириллических начертаний. После этого шрифт определен как базовый для вывода на дисплей и в документ.

2.3.6 Верстка и дизайн страниц веб-приложения

Верстка страниц веб-приложения абсолютно везде является табличной, причем сами таблицы являются серверными элементами <asp:Table runat=«server»> и исполняются на сервере. Такой подход имеет как минусы так и плюсы. Из минусов - невозможность проектирования страниц в режиме дизайнера. Вся верстка и дизайн велись в режиме редактирования html-разметки. Однако из плюсов - возможность обращения к макетной сетке как к северному элементу и вытекающие отсюда последствия: событийно-управляемые изменения дизайна и компоновки.

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

Учитывая, что у предпринимателя нет своего фирменного стиля, было решено использовать фирменные цвета компании Ford: оттенки синего с легким фиолетовым оттенком (основной цвет гаммы #333366). Такая цветовая гамма должна подсказывать клиентам узкую направленность деятельности предпринимателя и как следствие высокий профессионализм в отрасли.

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

Единообразие верстки и оформления во многом обеспечивается использованием шаблона оформления, описанного в основном MasterPage файле. В соответствии с выбранной разметкой шаблон представляет собой шапку, панель навигации, поле для контента и подвал (рисунок 2.6). Все страницы приложения загружаются как страницы содержимого в описанный выше шаблон. И даже страницы управления контентом, использующие свой собственный AdminMasterPage тоже разворачиваются во внешнем шаблоне (рисунок 2.7).

Рисунок 2.6 - Шаблон оформления страниц, определенный в MasterPage.master

Рисунок 2.7 - Шаблон оформления страниц управления контентом

Объявление стилей оформления элементов страниц преимущественно осуществлено во внешнем .CSS файле, что облегчает их модификацию.

Выводы

3.1 Общие сведения об информационной подсистеме