Разработка информационной подсистемы учета заявок покупателей на автомобильные комплектующие для индивидуального предпринимателя Ворончихина Н.П.
Дипломная работа - Компьютеры, программирование
Другие дипломы по предмету Компьютеры, программирование
кое представление сущности Заказ
Поле данныхТип данныхДопустимость неопределенных значенийreserve_idvarchar(100)Нетreserve_datedatetimeНетcontact_infovarchar(200)Даcontact_phonevarchar(15)ДаacceptedbitНетsendedbitНет
Сущность Запчасти заказа будет представлена в виде таблицы reserve_parts (таблица 2.12).
Таблица 2.12 - Физическое представление сущности Запчасти заказа
Поле данныхТип данныхДопустимость неопределенных значенийreserve_idvarchar(100)Нетpart_idvarchar(30)НетquantityintНет
Даталогическая модель отражена в виде схемы физической ER-модели БД и вынесена в приложение А.
2.3 Разработка программной части информационной подсистемы
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-полей серверной формы приложения. При выполнении пользователей каких-либо манипуляций изменяющих элементы управления (к примеру, выбор пунктов в выпадающих меню) их состояние будет со