2.3. Реализация уровня данных (Data Access Layer)

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

Реализован паттерн Repository, инкапсулирующий логику работы с базой данных. Это позволяет бизнес-логике (Service Layer) не зависеть от конкретной СУБД.

Особенности реализации массовой вставки данных (Seeding):

Для корректного сравнения производительности необходимо оперировать большими объемами данных (10 000 – 20 000 записей). Обычная циклическая вставка (INSERT INTO...) в SQLite работает медленно из-за того, что каждый запрос открывает и закрывает файл базы данных.

Для оптимизации был использован механизм транзакций:

Листинг 1 – механизм транзакций

db.serialize(() => {

db.run("BEGIN TRANSACTION");

const stmt = db.prepare("INSERT INTO students (...) VALUES (?, ?, ?)");

for (let i = 0; i < count; i++) {

stmt.run(...);

}

stmt.finalize();

db.run("COMMIT");

});

Данный подход позволил сократить время генерации 20 000 записей с нескольких минут до 1-2 секунд.

2.4. Реализация soap-сервиса

Разработка SOAP-сервиса выполнена по подходу Contract First (сначала контракт). Это означает, что разработка началась с проектирования файла WSDL, который жестко регламентирует типы данных и форматы сообщений.

Структура WSDL-контракта:

Файл student.wsdl определяет:

• Сложный тип Student, включающий поля id (int), name (string), specialization (string), course (int).

• Операцию getStudents, возвращающую массив элементов (используется атрибут maxOccurs="unbounded").

• Операцию createStudent, принимающую параметры и возвращающую созданный объект.

На стороне сервера используется библиотека soap, которая "слушает" определенный маршрут (/soap) и автоматически:

1. Парсит входящий XML-конверт.

2. Валидирует его на соответствие WSDL.

3. Вызывает соответствующую JavaScript-функцию из объекта serviceObject.

4. Сериализует результат выполнения функции обратно в XML.

2.5. Реализация rest-сервиса

REST-сервис реализован на базе фреймворка Express.js. В отличие от SOAP, здесь отсутствует строгий контракт на уровне протокола. Маршрутизация запросов:

• GET /api/students – Получение списка.

• POST /api/students – Создание записи.

• GET /api/admin/stats – Получение статистики БД.

Для обеспечения CORS (Cross-Origin Resource Sharing) настроены соответствующие заголовки, позволяющие клиентскому приложению (работающему на порту 5173) обращаться к серверу API (порт 8000).

2.6. Реализация клиентского приложения и сбор метрик

Клиентская часть представляет собой SPA (Single Page Application). Основная сложность заключалась в реализации работы с SOAP-протоколом в браузере, так как нативные инструменты (fetch, axios) не поддерживают SOAP "из коробки".

Механизм работы с SOAP на клиенте:

1. Формирование запроса: XML-конверт формируется вручную с использованием шаблонных строк (Template Literals).

Листинг 2 – использование шаблонных строк

const xml = `<soapenv:Envelope...><tns:getStudentsRequest/></soapenv:Envelope>`;

2. Отправка: Используется fetch с заголовком Content-Type: text/xml.

3. Парсинг: Полученная от сервера XML-строка преобразуется в DOM-дерево с помощью DOMParser [7]. Далее происходит ручной обход дерева. Основная трудность заключалась в поиске нужных узлов, так как браузеры по-разному обрабатывают префиксы пространств имен (например, тег может называться tns:students или просто students).

Листинг 3 – итеративный алгоритм для извлечения данных

const nodes = doc.getElementsByTagName('students');

for (let i = 0; i < nodes.length; i++) {

// Ручное извлечение текста из каждого дочернего узла

const id = nodes[i].getElementsByTagName('id')[0]?.textContent;

// Приведение типов (String -> Number)

}

Методика замера производительности:

Для получения объективных данных о производительности была разработана функция-обертка measure. Она фиксирует метки времени с высокой точностью (performance.now()) на трех этапах:

1. Начало запроса.

2. Получение сырого ответа (конец сетевой фазы).

3. Окончание преобразования данных в JavaScript-объекты (конец фазы парсинга).

Это позволило разделить общее время выполнения («Total Duration») на сетевую составляющую («Network Time») и вычислительную составляющую («Parsing Time»), что является ключевым аспектом данного исследования.