Архитектура серверной части приложения

 

Использование паттерна MVCпозволяет отделить логику, взаимодействие с данными и представление. И ASP.NETMVCпозволяет легко это реализовать. Однако, не смотря на такое разделение, приложение по-прежнему является одним целым. И уровень представления, и уровень логики взаимодействуют с моделями. В случае, если будет необходимо изменить представление (например, использовать WEBAPI), то изменения также будут затронуты и на уровне логики, а возможно и на уровне данных. Для решения данной проблемы можно использовать трехуровневую архитектуру приложения.

Классическая трехуровневая система состоит из следующих уровней:

 

Рис. 2 Схема трёхуровневой системы

 

Presentation layer (уровень представления): это тот уровень, с которым непосредственно взаимодействует пользователь. Этот уровень включает компоненты пользовательского интерфейса, механизм получения ввода от пользователя. Применительно к asp.net mvc на данном уровне расположены представления и все те компоненты, который составляют пользовательский интерфейс (стили, статичные страницы html, javascript), а также модели представлений, контроллеры, объекты контекста запроса.

Business layer (уровень бизнес-логики): содержит набор компонентов, которые отвечают за обработку полученных от уровня представлений данных, реализует всю необходимую логику приложения, все вычисления, взаимодействует с базой данных и передает уровню представления результат обработки.

Data Access layer (уровень доступа к данным): хранит модели, описывающие используемые сущности, также здесь размещаются специфичные классы для работы с разными технологиями доступа к данным, например, класс контекста данных Entity Framework. Здесь также хранятся репозитории, через которые уровень бизнес-логики взаимодействует с базой данных.

Каждый уровень имеет собственные модели. Уровень представления содержит модели представления, уровень бизнес-логики использует специальные промежуточные модели для передачи данных DTO (Data Transfer Object), уровень доступа к данным собственно модели, описывающие сущности базы данных.

Крайние уровни не могут взаимодействовать между собой, то есть уровень представления (применительно к ASP.NET MVC, контроллеры) не могут напрямую обращаться к базе данных и даже к уровню доступа к данным, а только через уровень бизнес-логики. Уровень доступа к данным не зависит от других уровней, уровень бизнес-логики зависит от уровня доступа к данным, а уровень представления - от уровня бизнес-логики.

 

Структура базы данных

 

Рис. 3 ER-диаграмма данных

 

Для доступа к данным было решено использовать EntityFrameworkи подход CodeFirst. При данном подходе сначала создаётся классы, описывающие сущности, а после EF генерирует таблицы в базе данных.

Также для системы авторизации и аутентификации используется ASP.NETIdentity. Данная система также использует EntityFramework для взаимодействия с данными. В результате получилась база данных, изображенная на рисунке 3.

Всего было создано 8 таблиц в базе данных.

AspNetUsers – основная таблица, используемая ASP.NETIdentity.В ней хранится информация о пользователях сайта, связанная с аутентификацией и авторизацией. Например: логин, электронная почта, хэш пароля. Также было добавлено поле, хранящее дату регистрации пользователя.

AspNetUserClaims – таблица, хранящая набор клеймов (claim). Claim представляет иную модель авторизации по сравнению с ролями. Грубо говоря, claim содержит некоторую информацию о пользователе, например, адрес электронной почты, логин, возраст и т.д. И эта информация позволяет идентифицировать пользователя и наделить его соответствующими правами доступа. Но приложением данная таблица не используется.

AspNetUserLogins – таблица логинов пользователя. В ней хранятся данные, если пользователь авторизуется через сторонние сервисы. Но так как эта функция не была реализована в приложении, данная таблица будет пустая.

AspNetRoles – таблица хранит роли пользователей. Всего в приложении две роли – «user» и «admin». По умолчанию каждый пользователь относится к роли «user».

AspNetUserRoles – в данной таблице хранятся соотношения пользователей и ролей. Т.е. какой пользователь, к какой роли относится.

UserProfiles – данная таблица уже не относится к ASP.NETIdentity. В ней хранится дополнительная информация о пользователе(если такая была указана).

Posts – в таблице хранятся посты, добавляемые пользователями. Таблица включает в себя такие поля:

 

· Id– идентификатор поста

· UserId – идентификатор пользователя, опубликовавшего пост

· Title– заголовок поста

· Body– само содержимое (текст) поста

· PublishDate– дата публикации поста

· Deleted– флаг, указывающий является ли пост удалённым

 

Likes – хранит информацию о оценках пользователей постов.