Создание базы данных на основе полученных данных
Следующей задачей, требующей решения при разработке приложения, является создание такой базы данных, доступ к которой клиентское приложение могло бы получить с любого компьютера. Соответственно, для ее решения необходимо хранить базу на сервере с поддержкой MySQL, а серверному приложению обеспечить постоянное соединение. В качестве сервера был выбран локальный сервер Denwer, который в условиях разработки приложения отвечает всем требуемым запросам. Для соединения парсера с сервером используется библиотека MySQLConnector/Net.
Посредством вышеупомянутой библиотеки, адреса сервера и данных для авторизации создается команда для подключения к серверу Denwer. Следующим действием определяется, пусты ли таблицы в базе данных или нет, и, в зависимости от этого, составляется SQL-запрос, который либо добавляет в таблицу построчно данные из полученной общей базы, либо обновляет уже имеющиеся поля по названию предмета, после чего запрос выполняется. Стоит отметить, что при запуске серверного приложения происходит однократное подключение, а затем в цикле с условием выхода при нажатии на кнопку Escпроисходит постоянный парсинг сайтов идобавление\обновление записей в базе сервера. Результат выполнения SQL-запроса можно увидеть на рисунке 3.5.
 |
Рисунок 3.5 – База предметов и цен на сервере
Написание логики работы клиентского приложения
После окончания разработки серверной части проекта необходимо приступать к созданию клиентской его части. Данное приложение должно уметь обращаться к созданной базе – это будет достигнуто таким же способом, как и в серверном приложении, а именно: с использованием библиотеки MySQLConnector/Net.Результаты обращения к базе необходимо выводить в такую структуру, которая бы позволяла наглядно отображать все значения, сортировать их в требуемой пользователю последовательности. Такой структурой будет являться табличное представление. Также необходимо, чтобы результаты обращения к базе можно было отсеивать по выбранным фильтрам. Причем стоит отметить, что фильтрация должна происходить уже после запроса к базе, а не задавать ограничения во время его выполнения. Этим достигается динамическая фильтрация результатов. В качестве параметров фильтрации были выбраны следующие пункты:
|
|
|
· фильтрация по давности обновления базы площадки;
· фильтрация по названию предмета;
· фильтрация по цене («от» и «до») для обеих площадок;
· фильтрация по разнице цен в процентах («от» и «до») для обеих площадок.
Помимо этого, необходимо добавить возможность пользователю изменять настройки комиссий на представленных площадках, поскольку в зависимости от комиссии процент разницы в цене будет отличаться. Соответственно, расчет разницы в цене должен также производиться уже после обращения к базе. Настройки комиссии будут сохраняться в файл, чтобы у пользователя не возникало необходимости вводить значения при каждом запуске программы.
|
|
|
Разработка дизайна клиентского приложения
Для создания макета клиентского приложения использовалась программа BalsamiqMockups, имеющая в своем арсенале компоненты визуального приложения, идентичные компонентам MicrosoftVisualStudio.
 |
Основное предназначение будущего приложения – таблица сравнения цен на площадках, поэтому она и должна стать основной страницей этого приложения. Получившийся макет изображен на рисунке 3.6.
Рисунок 3.6 – Макет окна «Таблица сравнения цен»
Как можно заметить, интерфейс отличается минималистичным дизайном, что было заявлено как одно из требований к будущему приложению. В верхней части окна располагаются выпадающие списки с названиями площадок и кнопка «Показать», по нажатию на которую будет происходить обращение к базе и заполнение таблицы, занимающей бОльшую часть экрана. Между ней и описанными выше компонентами находятся поля для ввода значений, на основе которых будет происходить фильтрация.
|
|
|
Помимо основного окна, необходимо создать окно с настройками значений комиссий на имеющихся в базе площадках, о чем говорилось ранее. Макет этого окна представлен на рисунке 3.7.
Рисунок 3.7 – Макет окна «Настройки»
Если вернуться к первому пункту разработки проекта, а именно: к анализу уже существующих решений, то стоит упомянуть, что практически каждый из ресурсов предоставляет возможность поиска по базе конкретной площадки. В связи с этим было решено реализовать данную функцию в будущем проекте. Макет страницы поиска по базе изображен на рисунке 3.8.
Рисунок 3.8 – Макет страницы «База цен»
Следующим этапом после разработки макетов приложения стала разработка самого приложения. В ходе ее было решено отказаться от концепции отдельных окон в пользу вкладок с разделами. Также реализовано добавление названия предмета в буфер обмена при нажатии на ячейку с этим названием. Принаведении курсора на ячейки с ценами предметов появляются всплывающие подсказки, уведомляющие о том, когда в последний раз обновлялась информация о данном предмете на данной площадке.
|
|
|
Готовый дизайн приложения отражен на рисунках 3.9 – 3.11.
 |
Рисунок 3.9 – Вкладка «Таблица» клиентского приложения
 |
Рисунок 3.10 – Вкладка «База цен» клиентского приложения
 |
Рисунок 3.11 – Вкладка «Настройки» клиентского приложения
Тестирование
В результате выполнения предыдущих пяти пунктов были реализованы как серверная, так и клиентская части проекта. Работа серверной части была протестирована и продемонстрирована на рисунке 3.5. Следовательно, необходимо перейти к тестированию.
В первую очередь, необходимо протестировать основной функционал программы, а именно: работоспособность таблицы сравнения цен. Для демонстрации сортировки были выбраны ресурсы BitSkinsи OPSkins, а также отображение лишь первых десяти записей базы для большей наглядности. Результаты теста отражены на рисунке 3.12.
 |
Рисунок 3.12 – Тестирование работоспособности таблицы сравнения цен
Следующий этап тестирования приложения – тестирование работы фильтров. В течение этого этапа возникла необходимость ограничить список символов, которые пользователь может вводить в поля значений фильтров. Это было реализовано не очень изящным с точки написания кода, но действенным методом (листинг 3.3).
Листинг 3.3 – Пример реализации ограничения на вводимые символы
| if (textBox3.Text.Length > 0) { string buf = textBox3.Text.Substring(0, textBox3.Text.Length - 1); string symb = textBox3.Text.Substring(textBox3.Text.Length - 1); if (symb == "." || symb == ",") { if (!textBox3.Text.Contains(",") || !textBox3.Text.Contains(".")) textBox3.Text = buf + ","; else textBox3.Text = buf; } else if (symb != "1" && symb != "2" && symb != "3" && symb != "4" && symb != "5" && symb != "6" && symb != "7" && symb != "8" && symb != "9" && symb != "0") { textBox3.Text = buf; } textBox3.SelectionStart = textBox3.Text.Length; } |
Заострять внимание на тестировании поиска по базе цен не является целесообразным, поскольку реализован он абсолютно так же, как и таблица, с поправкой на то, что необходимо выводить цену только одной площадки. В связи с этим следующим шагом будет тестирование сохранения и загрузки настроек. До этого были программно изменены значения комиссий, а затем просмотрен файл с настройками и повторно запущена программа. Результаты тестирования отображены на рисунках 3.13 – 3.15.
Рисунок 3.13 – Изначальные значения комиссии
Рисунок 3.14 – Новые значения комиссии
Рисунок 3.15 – Новые значения комиссии, записанные в файл
Таким образом, были протестированы все функции как серверного, так и клиентского приложения. Все выявленные недочеты были устранены в полном объеме.
Дата добавления: 2018-08-06; просмотров: 238; Мы поможем в написании вашей работы! |
Мы поможем в написании ваших работ!