realization - master - DexScen/ProjectPOH

realization
225 строк29 KB
Александр
changes
14 май 2026, 15:02
14 май 2026, 15:023f3feb2
3. РЕАЛИЗАЦИЯ СИСТЕМЫ
3.1. Реализация серверной части
В рамках данного проекта серверная часть была реализована на РНР-
фреймворке Laravel. Серверная часть разработана в формате АРІ и предназначена для обработки запросов от клиентской части приложения, предоставляя доступ к данным и функционалу через RESTful интерфейсы.
Фреймворк Laravel был выбран в качестве основной технологии раз-
работки серверной части, так как он предоставляет современную архитектуру MVC, которая обеспечивает разделение логики, представления и дан-ных. Laravel поддерживает построение АРІ с использованием маршрутов, контроллеров и ресурсов. Кроме того, данный фреймворк имеет встроенные механизмы аутентификации и авторизации. Его гибкость и масштабируе-мость при работе с базами данных достигается благодаря использованию
Eloquent ORM.
Традиционная архитектура MVC предполагает разделение приложе-
ния на три основных компонента, которые представлены ниже.
1. Model - отвечает за данные и бизнес-логику.
2. View - отвечает за отображение данных пользователю.
3. Controller - обрабатывает пользовательский ввод и взаимодей-
ствует с Model и View.
В данном проекте классическая архитектура MVC не используется в
чистом виде, так как серверная часть реализована как АРІ и не включает компонент View, тем самым остаются только Model и Controller.
Маршруты АРІ структурированы таким образом, чтобы поддерживать
принципы REST. Валидация данных осуществляется на уровне запросов с использованием встроенных средств Laravel.
Для безопасного доступа к закрытым ресурсам используется аутенти-фикация на основе JWT (JSON Web Tokens) [21] и refresh-токены. JWT применяется для передачи информации об аутентифицированном пользователе и содержит закодированные данные, такие как идентификатор
пользователя, его имя и срок действия токена. Refresh-токены используются для продления сессии без необходимости повторного ввода учетных дан-ных. В отличие от JWT, они хранятся на сервере и имеют более длительный срок действия.
Описание структуры серверной части проекта
Стандартная структура проскта на фрсймворк Laravel организована
в соответствии с общепринятыми принципами модульности и разделения ответственности. Данная структура была расширена. Основным изменением является введение сервисного слоя - специализированных классов, содержащих бизнес-логику приложения. Контроллеры в данном случае вы-
полняют минимальную охооту, выступая посимушественно в роли инишие-
торов сервисов и обработчиков НТТР-запросов.
Текущая структура Laravel проекта представлена на рисунке 15.
Casts
28
› DEvents
xcoption
Http
• & Controlke
• E Requeste
Resource:
Model
Nottication
>mpirans
Providers
Services
wo helpers,php
Рисунок 15 - Структура серверной части проекта
Для обеспечения строгой типизации и валидации данных между сло-
ями приложения были внедрены DTO (Data Transfer Objects).
Описание назначения директорий серверной части проекта приведено
ниже.
1. Casts - кастомные преобразователи атрибутов моделей.
2. Classes - вспомогательные классы для бизнес-логики.
3. Dto - объекты для передачи данных между слоями приложения.
4. Enums - перечисления.
5. Events - классы событий, в том числе WebSocket событий.
6. Exceptions - кастомные исключения.
7. Controllers - контроллеры для обработки запросов.
8. Middleware - промежуточное ПО для фильтрации запросов.
9. Requests - классы для валидации входящих запросов.
10. Resources - классы для преобразования данных.
11. Models - модели Eloquent для работы с БД.
12. Notifications - классы уведомлений.
13. Observers - наблюдатели за изменениями моделей.
14. Parents - родительские абстрактные классы.
15. Providers - сервис-провайдеры для регистрации сервисов.
16. Rules - кастомные правила валидации.
17. Services - сервисные классы для бизнес-логики.
18. Traits - трейты для повторного использования кода.
Описание конечных точек АРІ
Клиентская часть взаимодействует с сервером через RESTful API, по-
строенное на стандартных НТТР-методах (GET, POST, PUT, DELETE), чТО обеспечивает предсказуемую структуру запросов и прозрачную логику ра-боты. Однако в некоторых случаях допускаются отклонения от строгих
REST-правил, когда это необходимо для реализации специфичной логики, например запрос на авторизацию. Конечные точки АРІ можно разделить на несколько блоков, которые описаны ниже.

Блок авторизации включает маршруты, обеспечивающие вход пользователя в систему, обновление токенов доступа с использованием refresh-то-кена, а также восстановление доступа через механизм сброса пароля с подтверждением по электронной почте. Спецификации конечных точек блока авторизации представлены в таблицах 1-4 приложения А.
В блоке управления пользователями реализованы функции регистра-
ции, получения и редактирования данных пользователя, подтверждения электронной почты, смены пароля и изображения профиля. Также предусмотрен механизм поиска пользователей по имени. Спецификации конечных точек блока управления пользователями представлены в таблицах 5-13 приложения A.
В блоке дружеских связей реализовано взаимодействие между поль-
зователями: отправка и принятие заявок в друзья, отмена и отклонение за-явок, удаление из списка друзей, а также просмотр списков друзей и всех заявок. Спецификации конечных точек блока дружеских связей представлены в таблицах 14-19 приложения А.
В блоке игрового процесса предусмотрены маршруты, отвечающие за
создание комнат, подключение к ним, поиск случайного соперника через очередь. Также реализованы механизмы отправки и принятия приглашений в игру, завершения игры и фиксации результата. Пользователь имеет воз-можность просматривать список своих игр и список лучших игроков. Спе-цификации конечных точек блока игрового процесса представлены в таблицах 20-33 приложения А.
Большинство маршрутов API требуют аутентификации с использова-
нием JWT-токенов. Такая структура АРІ обеспечивает четкое разграничение логики, удобство поддержки и интеграции с клиентской частью.
Реализация WebSocket каналов
WebSocket каналы делятся на несколько типов в зависимости от
уровня доступа и назначения. Публичные каналы доступны всем пользователям без ограничений. Приватные каналы требуют аутентификации и
используются для передачи данных конкретному пользователю. Каналы присутствия (presence-каналы) позволяют отслеживать список подключен-ных пользователей, что полезно для реализации многопользовательских взаимодействий. Такой подход обеспечивает гибкость в организации обмена данными в реальном времени и безопасность передачи информации.
WebSocket каналы и их краткое описание представлены ниже.
1. Приватный канал users. <userld>.online. Данный канал необходим
для определения статуса онлайна пользователя. Это позволяет узнать, что пользователь зашел на сайт или покинул его.
2. Приватный канал users.<userld>.events. Данный канал необходим
для рассылки уведомлений пользователю, а также сообщений о создании комнаты.
3. Канал присутствия rooms.<roomld>›. Данный канал необходим для
запуска игры. Подключится к нему можно только пока комната не запол-нена. После создания игры, в этот канал отправляется сообщение с иденти-фикатором игры.
4. Канал присутствия games. ‹gameld>. Данный канал необходим для
обмена ходами пользователей. Подключится к нему могут только участники игры. При завершении игры, оправляется сообщение об успешном или неудачном завершении.
Для определения выхода пользователя из каналов применяются веб-
хуки, на которые WebSocket-сервер отправляет НТТР запрос при срабаты-вании нужного события. Реализованные веб-хуки представлены ниже.
1. Веб-хук /broadcasting/webhook-online. Вызывается при выходе
пользователя из канала users. ‹userld>.online. При вызове веб-хука пользова-
тель удаляется из очереди на поиск соперника, а также удаляются все его отправленные приглашения на игру. Также меняется статус онлайна.
2. Веб-хук /broadcasting/webhook-game. Вызывается при выходе
пользователя из канала games.<gameld>. При вызове веб-хука, если игра
еще не была завершена, пользователь покинувший канал признается проигравшим.
Описание логики запуска и завершения игры
Механизм запуска игрового процесса реализован через систему вре-
менных игровых комнат, которые служат промежуточным состоянием перед началом матча, где пользователи расставляют свои корабли. В комнату можно попасть следующими способами:
1) запуск поиска случайного противника;
2) принятие приглашения в игру от друга;
3) запуск игры по ссылке.
Технически игровая комната представляет собой временную запись в
хранилище Redis, содержащую идентификаторы участников и их статус го-говности, с установленным временем жизни для автоматической очистки неактивных сессий. После окончания срока жизни, комната станет
неактивна.
Выбор Redis в качестве хранилища обусловлен требованиями к высо-
кой скорости операций чтения и записи, а также небольшом сроке хранения
данных.
Процесс поиска соперника реализован через очередь ожидания в
Redis. При появлении в очереди подходящей пары игроков система автома-тически создает игровую комнату и уведомляет участников через WebSocket-соединение.
После подтверждения готовности обоими участниками комната уда-ляется, в основной базе данных MySQL создается запись о игре, а пользователям отправляется событие по WebSocket-соединению, тем самым запуская игру. Стоит отметить, что при запуске игры, на сервере случайным образом определяется пользователь, который делает первый ход в игре.
Игровой процесс осуществляется через обмен сообщениями по
WebSocket-соединению, что обеспечивает минимальные задержки при передаче ходов.
Для предотвращения манипуляций с результатами игры реализована
система верификации: финальные результаты от обоих участников сравниваются на сервере перед окончательным завершением матча. Для этого
также используется хранилище Redis. В случае расхождений результатов игры выбрасывается ошибка. Если пользователь покинет страницу во время игры, он автоматически будет признан проигравшим. После завершения игры, у пользователей обновляется статистика.
Также на сервере в фоновом режиме происходит мониторинг и завер-
шение игр, которые по какой-либо причине не завершились. Такие игры признаются прерванными.
3.2. Реализация клиентской части
Клиентская часть веб-приложения реализована как одностраничное
SPA (Single Page Application) приложение с использованием фреймворка
Vue.js, что обеспечивает динамическое обновление интерфейса без переза-грузки страницы. Архитектура клиентской стороны построена на компо-нентном подходе, где каждый независимый элемент интерфейса (страницы, модальные окна, игровые поля) представлен в виде переиспользуемых компонентов Vue, что способствует поддержанию чистоты кода и упрощает разработку.
B Vue.js реализуется паттерн MVVM. Это архитектурный паттерн,
позволяющий разделить архитектуру на три функциональные части, кото-
рые представлены ниже.
1. Model - описывает используемые данные и содержит основную
логику программы;
2. View - определяет визуальный интерфейс, через который пользо-
ватель взаимодействует с приложением;
3. ViewModel - служит прослойкой между моделью и представле-
нием посредством механизма привязки данных.
Для организации навигации между разделами приложения задейство-
ван Vue Router [22], который предоставляет механизм маршрутизации на стороне клиента с поддержкой динамических параметров URL и защищен-
ных маршрутов.
Для взаимодействия с API используется библиотека Axios [23], обес-
печивающая выполнение НТТР-запросов. Она настроена с параметрами и обработчиками ошибок, включая автоматическое обновление JWT-токенов
при истечении их срока действия.
Основная логика вынесена в сервисный слой, представляющий собой
TypeScript-файлы, что позволяет отделить логику от представления и улуч-шает структурированность кода, делая его более понятным и легким для поддержки.
Для сборки веб-приложения применяется сборщик Vite [24]. В про-
цессе сборки исходный код на языке, таком как Туре и SCSS, преобра-
зуется в стандартный JavaScript, CSS и HTML.
Описание структуры клиентской части проекта
Структура клиентской части проекта представлена на рисунке 16.
v O src
> D api.
> assets.
> O components
> O composables
> O enums
>口helpers
> O interfaces
> O models
> O routes.
> O services
> O views
TS app.config.ts
App.vue
Рисунок 16 - Структура клиентской части проекта
Описание назначения директорий клиентской части проекта приве-
дено ниже.
1. Арі - содержит файлы с функциями для отправки запросов к АРІ.
2. Assets - содержит статические ресурсы.
3. Components - Vue-компоненты, которые можно переиспользовать
в разных частях приложения.
4. Composables - файлы с переиспользуемыми функциями, исполь-
зующие Composition API.
5. Enums - перечисления.
6. Helpers - вспомогательные функции.
7. Interfaces - интерфейсы и типы Туре.
8. Models - модели данных, например модель корабля.
9. Routes - конфигурация маршрутов для Vue Router.
10. Services - сервисы для бизнес-логики приложения.
11. Views - страницы приложения.
12. App.vue - корневой компонент Vue, в котором формируется при-
ложение, подключаются связи.
13. app.config.ts - настройки приложения, в том числе игровые.
Описание маршрутов Vue Router
Реализованная система маршрутов включает как публичные пути, до-
ступные всем пользователям, так и защищенные маршруты, доступные
только авторизованному или только неавторизованному пользователю.
Также присутствуют динамические маршруты, где параметры передаются непосредственно через URL. Такая организация маршрутизации обеспечивает четкую структуру приложения и удобное управление правами доступа.
Рассмотрим реализованные маршруты веб-приложения с их
описанием:
1) корневой маршрут - главная страница, на которой пользователь
выбирает режим игры;
2) /login - страница авторизации, где пользователь вводит данные
для входа:
3) /register - страница регистрации, где пользователь вводит данные
для регистрации;
4) /friends - страница со списком друзей и заявок в друзья;
5) /users/<userld> - страница с профилем пользователя;
6) /verify-email/<id>/<hash> - маршрут для подтверждения почты;
7) /reset-password/<token> - страница для сброса пароля;
8) /play - страница игры, где происходит расстановка кораблей и иг-
ровой процесс;
9) /games - страница со списком игр пользователя;
10) /invites - страница со списком приглашений в игру.
Страницы авторизации, регистрации и сброса пароля доступны только неавторизованному пользователю, а страницы со списком друзей, приглашений и игр доступны только авторизованному.
Скриншоты реализованного интерфейса веб-приложения для дескто-
пной версии приведены на рисунках 1-8 приложения Б, для мобильной - на рисунках 9-16 приложения В.
Описание системы уведомлений
Веб-приложение оснащено системой уведомлений, реализованной в
виде интерактивных всплывающих элементов, расположенных в нижнем
правом углу экрана.
Система включает три основных типа уведомлений, которые отлича-
ются по цвету: информационные сообщения, уведомления об успехе и сообщения об ошибках. Особую категорию составляют уведомления с элемен-
тами управления, позволяющие пользователю принимать или отклонять
входящие запросы на дружбу и игровые приглашения.
Система уведомлений интегрирована с основными модулями веб-при-
ложения. Обработчик API-запросов перехватывает ошибки, автоматически преобразуя их в соответствующие уведомления. Для событий реального
времени выделен специализированный WebSocket-канал, обрабатывающий
уведомления, такие как приглашения в игру, подключение в комнату и дру-
гие. Дополнительно реализован механизм валидации входных данных с мгновенным отображением ошибок через систему уведомлений.
Выводы по третьей главе
В данной главе представлена реализация веб-приложения с четким
разделением на серверную и клиентскую части.
Серверная часть веб-приложения построена на фреймворке Laravel с
архитектурой RESTful API. Также реализована поддержка WebSocket-co-единений для обеспечения взаимодействия в реальном времени. Аутенти-фикация пользователей реализована с использованием JWT-токенов. Это обеспечило надежную защиту пользовательских данных и эффективное взаимодействие между клиентом и сервером.
Клиентская часть разработана с использованием Vue.js в формате од-
ностраничного приложения (SPA), что позволило достичь высокой отзыв-чивости интерфейса и плавности навигации. Благодаря компонентной архитектуре и применению Vue Router и Axios, обеспечено удобное управление маршрутами и взаимодействие с сервером. Интеграция WebSocket-соедине-ний на клиенте позволила добавить поддержку функций реального времени.
Таким образом, реализованная система демонстрирует успешное при-
менение современных технологий и архитектурных подходов для создания надежного веб-приложения, обеспечивающего качественный пользователь-ский опыт.
к