Бизнес-логика находится на втором слое и отделена от первого. Здесь сосредоточена вся основная функциональная логика приложения. Этот слой взаимодействует как с клиентом, так и с третьим слоем - слоем доступа к данным.
Логика доступа к данным выделена в третий слой. Здесь по запросу бизнес-логики происходит формирование SQL-запросов и обращение к СУБД, после чего извлеченные данные передаются на второй слой.
По сравнению с другими трехуровневая архитектура имеет следующие достоинства:
- Масштабируемость. В приложениях, которые сильно нагружены, можно распределить нагрузку между несколькими серверами приложений;
- Конфигурируемость. Отделение уровней друг от друга позволяет быстро и простыми средствами перенастроить систему при возникновении сбоев или при плановом обслуживании на одном из уровней;
- Высокая безопасность. Клиент не обращается напрямую к данным, все запросы проходят через сервер приложений, благодаря чему появляется возможность проверить корректность этих запросов;
- Высокая надёжность. В момент отказа оборудования или при пиковых нагрузках можно добавить еще один сервер, который будет обрабатывать запросы клиента;
- Низкие требования к скорости канала между клиентом и сервером приложений;
- Низкие требования к производительности и техническим характеристикам клиента, отсюда вытекает большая доступность конечному пользователю.
Тем не менее трехуровневая архитектура не лишена и своих недостатков, среди которых можно выделить:
- Более высокая сложность при создании приложений;
- Сложнее в разворачивании и администрировании;
- Высокие требования к производительности серверов приложений и сервера базы данных, а, значит, и высокая стоимость серверного оборудования;
- Высокие требования к скорости канала между сервером базы данных и серверами приложений.
2.3 Выбор средств разработки
Для реализации серверной части был выбран язык программирования Java. На сегодняшний момент язык Java является одним из самых распространенных и популярных языков программирования.
В серверной части были выбраны следующие технологии:
- Spring Framework - универсальный фреймворк с открытым исходным кодом для Java-платформы. Spring обеспечивает решения многих задач, с которыми сталкиваются Java-разработчики и организации, которые хотят создать информационную систему, основанную на платформе Java.
- Spring Boot - компонент Spring, помогающий легко создавать и запускать полноценные web-приложения, благодаря встроенным контейнерам, таким как, например, Tomcat или Jetty. [2] Именно за счет этого компонента возможна простая установка на любой сервер.
- Spring Security - компонент, предоставляющий механизмы построения систем аутентификации и авторизации, а также другие возможности обеспечения безопасности для приложений, созданных с помощью Spring. [3]
- Maven - инструмент для сборки Java проекта: компиляции, создания jar- или war-файла, создания дистрибутива программы, генерации документации и многого другого. Основная идея заключается в описании зависимостей и структуры проекта в файлах на языке POM.
- Lombok - проект по добавлению дополнительной функциональности в Java c помощью изменения исходного кода перед Java компиляцией. [4] Lombok, позволяет не писать некоторые часто используемые методы, а добавить их неявно с помощью одной строки кода.
- Spring MVC - компонент, обеспечивающий реализацию используемого в разработке паттерна Model-View-Controller;
- Hibernate - библиотека, которая предназначена для отображения объектов объектно-ориентированного языка в структуры реляционных баз данных.
Для реализации клиентской части был выбран React - JavaScript-фреймворк с открытым исходным кодом для разработки пользовательских интерфейсов. React значительно облегчает создание интерфейсов благодаря так называемому компонентному подходу. В React нет контроллеров, моделей, шаблонов и так далее - все есть компонент. Компонент - это строительная единица, из которой собирается весь интерфейс. [5]
Также при построении пользовательского интерфейса будет полезен Bootstrap 3 - свободный набор инструментов для создания сайтов и веб-приложений, включающий в себя HTML- и CSS-шаблоны оформления для всевозможных компонентов веб-интерфейса. [6]
Для контроля разработки был выбран Bitbucket - веб-сервис для хостинга проектов, основанный на системе контроля версий Git.
2.4 Проектирование базы данных
База данных состоит из 8 таблиц. Схема базы представлена на рисунке 2.3.
Рисунок 2.3 Схема базы данных приложения
Рассмотрим подробнее все таблицы базы данных:
Podcasts - таблица для хранения информации о подкастах.
Описание полей:
- id - уникальный идентификатор;
- authorId - id пользователя, который создал подкаст;
- name - название подкаста;
- description - описание подкаста;
- itunesLink - ссылка на ITunes подкаста;
- vkLink - ссылка на VK подкаста;
- twitterLink - ссылка на Twitter подкаста;
- facebookLink - ссылка на Facebook подкаста;
- episodeCount - счетчик эпизодов подкаста;
- subscribersCount - счетчик подписчиков подкаста;
- rating - счетчик рейтинга подкаста;
- genreId - id жанра, которому принадлежит подкаст;
- creationDate - дата создания подкаста.
Genres - таблица для хранения информации о жанрах подкастов.
Описание полей:
- id - уникальный идентификатор;
- name - название жанра.
Episodes - таблица для хранения информации о выпусках подкастов.
Описание полей:
- id - уникальный идентификатор выпуска;
- podcastId - id подкаста, которому принадлежит выпуск;
- description - описание выпуска;
- link - ссылка на аудиофайл выпуска;
- name - название выпуска;
- creationDate - дата создания выпуска.
Users - для хранения информации о пользователях.
Описание полей:
- id - уникальный идентификатор пользователя;
- username - логин пользователя для прохождения аутентификации при входе на сайт;
- password - пароль пользователя для прохождения аутентификации при входе на сайт;
- name - имя пользователя;
- email - электронный адрес пользователя;
- creationDate - дата регистрации пользователя.
Coauthors - таблица для хранения информации о соавторах.
Описание полей:
- id - уникальный идентификатор;
- podcastId - id подкаста, которому принадлежит соведущий;
- userId - идентифигатор пользователя.
Tweets - таблица для хранения сообщений в микроблогах.
Описание полей:
- id - уникальный идентификатор;
- podcastId - id подкаста, которому принадлежит сообщение;
- authorId - идентифигатор пользователя;
- authorUsername - логин автора сообщения;
- text - содержание сообщения;
- creationDate - дата создания сообщения.
Ratings - таблица для хранения записей об изменении рейтинга подкастов.
Описание полей:
- id - уникальный идентификатор;
- podcastId - id подкаста, которому изменили рейтинг;
- userId - идентифигатор пользователя, который изменил рейтинг;
- decision - решение пользователя. Может быть положительным или отрицательным.
Subscribes - таблица для хранения записей о подписках на подкасты.
Описание полей:
- id - уникальный идентификатор;
- podcastId - id подкаста, на который осуществлена подписка;
- userId - идентифигатор пользователя, который подписался на подкаст.
Связи, установленные в схеме:
Связь «один ко многим» установлена между таблицами:
- users и podcasts;
- users и coauthors;
- users sи subscribes;
- users и tweets;
- users и ratings;
- genres и podcasts;
- podcasts и episodes;
- podcasts и coauthors;
- podcasts и tweets;
- podcasts и ratings;
- podcasts и subscribes.
2.5 Проектирование пользовательского интерфейса
Пользовательский интерфейс - это набор программных и аппаратных средств, обеспечивающих взаимодействие пользователя с программой. Основу такого взаимодействия составляют диалоги. Каждый диалог состоит из отдельных процессов ввода/вывода, которые физически обеспечивают связь пользователя и программой. [7]
С помощью таких диалогов или панелей и будет строиться взаимодействие пользователей с сайтом. При регистрации, входе, создании нового подкаста, добавлении нового выпуска и тому подобных действиях пользователь увидит панель с необходимой информацией и полями ввода, заполнив которые, можно будет выполнить желаемое действие.
Основными страницами сайта будут главная страница и страница подкаста.
На рисунке 2.4 представлен макет главной страницы сайта, состоящий из блока поиска, находящегося слева и списка подкастов, находящегося по центру. От взаимодействий с блоком поиска должно меняться наполнение списка подкастов.
Рисунок 2.4 Макет главной страницы
На рисунке 2.5 представлен макет страницы подкаста, состоящий из блока информации о подкасте, находящегося слева, основного блока, находящегося по центру и переключателя, который также находится по центру. Основной блок имеет два режима: режим показа списка выпусков и показа микроблога подкаста. Этими режимами и управляет переключатель. При активном режиме микроблога - если пользователь имеет право добавить в него новую запись - под переключателем будет находиться панель ввода нового сообщения.
Рисунок 2.5 Макет страницы подкаста
На обоих макетах присутствует шапка сайта - поле, содержащее меню сайта, а также кнопку авторизации.
При помощи вышеописанных страниц и будет осуществляться основное взаимодействие с пользователем.
3. Реализация
3.1 Реализация серверной части
3.1.1 Структура серверной части
Серверная часть приложения была написана на языке Java. Весомое значение имел фреймворк Spring, который позволил упростить и ускорить разработку. Во многом за счет него была настроена взаимосвязь с базой данных, а также обеспечена безопасность приложения.
Всю серверную часть можно условно разделить на три уровня: уровень сервисов, уровень доступа к данным и уровень сущностей. Рассмотрим каждый из них подробнее.
Уровень сущностей включает в себя описание всех объектов, с которыми взаимодействует сервер, например, пользователь, подкаст, выпуск и так далее. Полный список сущностей можно увидеть на рисунке 3.1.
Рисунок 3.1 Список сущностей
Каждая сущность состоит из определенных свойств, которые ей присущи. Пример можно увидеть на рисунке 3.2, где описаны свойства объекта выпуска подкаста.
Рисунок 3.2 Описание сущности выпуска подкаста
Уровень доступа к данным обеспечивает связь между сервисами и базой данных, в нем описываются те действия, которые можно совершить над объектом. На рисунке 3.3 показан пример класса доступа к данным выпусков подкастов, где можно увидеть такие действия, как нахождение списка выпусков конкретного подкаста или удаление всех выпусков подкаста.
Рисунок 3.3 Класс доступа к данным выпуска подкаста
Последний слой - слой сервисов. Именно к данному слою обращается клиентская часть в процессе работы приложения. Классы этого слоя обрабатывают все необходимые запросы от клиента, взаимодействуя с классами слоя доступа к данным. Общение сервера с клиентом строится через адреса запросов. В большинстве случаев запрос включает в себя некоторые параметры или целые объекты с необходимыми данными. Например, на рисунке 3.4 можно увидеть запрос на изменение рейтинга подкаста, вместе с которым подается объект, содержащий информацию о голосовавшем пользователе, изменяемом подкасте и решении пользователя.
Рисунок 3.4 Запрос на изменение рейтинга подкаста
Блок-схему алгоритма, который содержится в данной функции можно увидеть на рисунке 3.5.
Рисунок 3.5 Блок-схема алгоритма изменения рейтинга подкаста
Другим примером может послужить запрос на подписку пользователя на подкаст. В данном случае запрос содержит не объект, а два числовых параметра - идентификаторы пользователя, и подкаста. Данный запрос представлен на рисунке 3.7, а его блок-схему можно увидеть на рисунке 3.6.
Рисунок 3.6 Блок-схема алгоритма подписки на подкаст
Рисунок 3.7 Запрос подписки на подкаст
3.1.2 Безопасность приложения
Важной частью приложения является его безопасность. Основной инструмент, использующийся для обеспечения безопасности пользователей в данном приложении - Spring Security. Он предоставляет множество методов защиты, один из них - защита от CSRF-атак.
CSRF (Cross-Site Request Forgery, также XSRF) - атака, которая приводит к тому, что хакер может выполнить на неподготовленном сайте массу различных действий от имени других, зарегистрированных посетителей.
Эффективным и общепринятым на сегодня способом защиты от CSRF-атаки является токен. Под токеном имеется в виду случайный набор байт, который сервер передает клиенту при входе на сайт, а клиент отправляет его серверу при каком-либо запросе. Защита сводится к проверке токена, который сгенерировал сервер, и токена, который прислал пользователь.
Требования к токену:
1. Уникальный токен для каждой операции;
2. Действует единожды;
3. Имеет размер, устойчивый к подбору;
4. Сгенерирован криптографически стойким генератором псевдослучайных чисел;
5. Имеет ограниченное время жизни.
Именно при помощи токена настроено разграничение прав пользователей. В файле «SecurityConfig» указаны все действия, которые может совершить рядовой пользователь, такие как просмотр подкастов, регистрация, просмотр статистики сайта и так далее. Для определенных действий уже понадобится авторизация и, соответственно, токен, описанный выше. Примером таких действий могут послужить удаление подкаста или добавление нового выпуска.