Commit 9f716a73 authored by Borodin Dmitriy's avatar Borodin Dmitriy

1. Finished description for front-end diagram.

parent f727e221
# Принципиальная схема взаимодействия объектов на уровне приложения ( **back-end** )
![Принципиальная схема взаимодействия объектов на уровне приложения ( **back-end** )](../static/structure_diagram_on_applycation_layer_back_end.png)
## Общие понятия
- **Data** - Элемент данных который является базовым классом для From, Insert, Persist, Cache.
- **Form** - Элемент данных который используется для работы с формой, все поля являются опциональными. Содержит метод валидации который может реализовать валидацию для полей внутри обхекта формы.
- **Insert** - Элемент который соответсвует схеме базы данных, но отсутствует в базе данных, преднаязначен только для записи в БД.
- **Persist** - Элемент данных хранящихся в базе данных.
- **Cache** - Производные данные от Persist(s) различных моделей, хранится в базе данных.
......@@ -4,23 +4,39 @@
## Общие понятия
- **UI компонент** - **Класс** и **Интерфейс** декларирующий свойства и действия которые необходимы для работы GUI. Компонент реализует часть GUI, не агрегирует и/или композирует другие **UI компоненты**, фактически это деталь для составления компазиций.
- **Data** - Элемент данных который является базовым классом для From, Insert, Persist, Cache.
- **Form** - Элемент данных который используется для работы с формой, все поля являются опциональными. Содержит метод валидации который может реализовать валидацию для полей внутри обхекта формы.
- **Insert** - Элемент который соответсвует схеме базы данных, но отсутствует в базе данных, преднаязначен только для записи в БД.
- **Persist** - Элемент данных хранящихся в базе данных.
- **Cache** - Производные данные от Persist(s) различных моделей, хранится в базе данных.
- **UI композиция** - **Класс** и **Интерфейс** декларирующий свойства и действия которые необходимы для работы GUI. Композиция агрегирует и/или композировать другие **UI компоненты** и **UI композиции**, но самостоятельно не реализует GUI, фактически это механизм.
- **UI компонент** - Компонент реализует часть GUI, **может агрегировать и/или композировать** другие **UI компоненты**. Является переносимым кодом и **`может быть использован для реализации любой предметной области`**.
## UI layer
- **UI композиция** - Композиция агрегирует и/или композировать другие **UI компоненты** и **UI композиции**. **`Реализовывает задачи конкретной предметной области, НЕ может использоваться для реализации другой предметной области.`** В рамках предметной области **НЕ** имеет внешних зависимостей.
- **Адаптер** - адаптирует Interface_1 ... Interface_N к требуемому интерфейсу.
Множество **Классов** реализующих все необходимые варианты GUI для приложения. Каждый **Класс** реализует **Интерфейс**, следовательно для получения экземпляра **Класса** необходимо удовлетворить интерфейс.
- **Репозиторий** - Класс который абстрагирует работу с коллекцией (Persist, Cache). Опционально можно дореализовать фильтер в Подкласс **Репозитория**.
В большинстве случаем **Интерфейс** `UI композиции` не совпадает с доступным API на уровне бизнес логики.
## UI layer
Для того чтобы удовлетворить **Интерфейс** `UI композиции`, применяется **шаблон адаптер**, который реализует **Интерфейс** `UI композиции` используя доступное API уровня бизнес логики.
**Зона отвественности включает в себя:**
`Не может зависеть от экземпляров других композиций, может только композировать другие UI композиции и UI компоненты.`
- Реализовать GUI определенный предметной областью.
**Реализуется** как множество **UI композиций** которые реализуют GUI предметной области.
## Adapter layer
Структурный класс, необходим только для преобразования интерфейсов уровня бизнес логики к интерфейсу **UI композиции**. Экземпляр адаптера создается в системе одноклатно и явялется синглтоном. Передается в конструктор **UI композиции**.
**Зона отвественности включает в себя:**
- Реализовать интерфейс **UI композиции** используя API слоя бизенс логики.
**Реализуется** как множество **Классов** реализующих интерфейс **UI композиции**, экземпляр которого существует единожды в системе (`singlton`).
Выполняет субуго структурную роль, не имеет полезной реализации, только реализует интерфейс композиции, используя имеющиеся API слоя бизнес логики.
Избавляет от **ХардКода** импортов бизнесслогики внутри фалов **UI композиций**, делая тем самым код компонентов и композиций, легко тестируемым и переносимым.
**`Не имеет связей с другими адаптерами.`**
......@@ -28,4 +44,77 @@
## Business logic layer
В общем случае
**Зона отвественности включает в себя:**
- **Хранение** и **работу** с объектами данных.
- **Хранение** и **работу** с коллекциями данных.
- Прослушивание WebSocket событий для (обновления коллекций данных, push нотификаций).
- Работу форм (заполнение, валидация, отправка).
- Обработку состояний фильтров.
- Контроль сессии и доступа к (композициям, колекциям, событиям).
### **Хранение** и **работу** с объектами данных
Реализуется как подкласс [CommonStore](https://gitlab.com/mitya-borodin/base-code/blob/master/packages/front/src/CommonStore.ts). Существует единожды в системе (`singleton`), содержит объект данных ,определенного типа, который можно изменить по средством формы.
### **Хранение** и **работу** с коллекциями данных
Реализуется как подкласс [Repository](https://gitlab.com/mitya-borodin/base-code/blob/master/packages/front/src/Repository.ts). Существует единожды в системе (`singleton`), содержит коллекцию данных определенного типа, каждый элемент коллекции можно изменить по средством формы.
### Прослушивание WebSocket событий для (обновления коллекций данных, push нотификаций)
Реализуется в базовых классах [Repository](https://gitlab.com/mitya-borodin/base-code/blob/master/packages/front/src/Repository.ts#L211) и [CommonStore](https://gitlab.com/mitya-borodin/base-code/blob/master/packages/front/src/CommonStore.ts#L107), как метод `receiveMessage` обрабатывающий сообщение.
Приверов реализации Push нотификаций на данный момент не существует.
### Работа форм (заполнение, валидация, отправка)
Реализуется как подкласс [RepositoryFormStore](https://gitlab.com/mitya-borodin/base-code/blob/master/packages/front/src/RepositoryFormStore.ts), [CommonStoreForm](https://gitlab.com/mitya-borodin/base-code/blob/master/packages/front/src/CommonStoreForm.ts) или реализация интерфейса [IFormStore](https://gitlab.com/mitya-borodin/base-code/blob/master/packages/front/src/interfaces/IFormStore.ts). Для каждой формы необходимо реализовать метод присвоения значений [RepositoryFormStore.changeAssign](https://gitlab.com/mitya-borodin/base-code/blob/master/packages/front/src/RepositoryFormStore.ts#L212), [CommonStoreForm.changeAssign](https://gitlab.com/mitya-borodin/base-code/blob/master/packages/front/src/CommonStoreForm.ts#L206).
Причем [IFormStore](https://gitlab.com/mitya-borodin/base-code/blob/master/packages/front/src/interfaces/IFormStore.ts) реализуется только для ситуаций когда данные формы не храняться в базе данных, может храниться только производная от этих данных, либо жти данные могут повлиять на сущесьвующие коллекции и объекты в системе.
Например: 1) Форма регистрация 2) Форма входа 3) Форма восстановления пароля.
Действия для выполнения которых необходимы данные, но один к одному эти данные не будут записаны в базу данных.
#### Валидация
##### Может выполняться следующими способами
- Непосредственно на объекте формы.
- В стороннем объекте, продуцируя производные данные **Cache** того же типа что и **Form** (используются все доступные коллекции и объекты системы).
##### Окружения для выполнения валидации
- Front-end, чаще всего это валидация на объекте формы.
- Front-end, в стороннем объекте, продуцируя производные данные **Cache** того же типа что и **Form** (используются все доступные коллекции и объекты системы), результатом будет обновление текущего объекта **Form**.
- Back-end, крайне редкий случай валидации на объекте формы.
- Back-end, в стороннем объекте, продуцируя производные данные **Cache** того же типа что и **Form** (используются все доступные коллекции и объекты системы), результатом будет web socket событие, которое обновит текущий объект **Form** на клиенте, таким образом пользователь получит обновленные результаты валидации.
### Обработка состояния фильтров
Фильтрацию можно дореализовать подклассу [Repository](https://gitlab.com/mitya-borodin/base-code/blob/master/packages/front/src/Repository.ts).
Фильтрацию можно реализовать как самостоятельный Класс, который реализует объект фильтра для указанной колекции.
**Пагинация**, как разновидность фильтрации дореализовывается в подклассе [Repository](https://gitlab.com/mitya-borodin/base-code/blob/master/packages/front/src/Repository.ts).
#### Возможные типы фильтрации
- Фильтрация имеющихся данных в коллекции.
- Фильтрация с запросом на сервер, применяется когда данных слишком много, чтобы загрузить их целиком на фронтенд.
### Контроль сессии и доступа к (композициям, колекциям, событиям)
Сессия и доступы зависят от текущего пользователя, и в частности от группы в которой он состоит.
Объект пользователя в большинстве случаев это экземпляр класса || подкласса [UserRepository](https://gitlab.com/mitya-borodin/base-code/blob/master/packages/front/src/UserRepository.ts).
При старте приложения проверяется наличие token в localStorage, если он есть то запрашиваются данные пользователя, если данные имеются, то выполняется процедура входа.
Если token не обнаружен в localStorage или данные небыли получены, то проиходит редирект на страницу входа.
В тех участках программы, где необходимо ограничить доступ по группе, реализуется условие на проверку в какой группе состоит текущий пользователь.
## Transport layer
Транспортный уровень, отвечает только за работу с HTTP, WebSocket протоколами. Отправка получение запросов, и удержание соединения в случае с WebSocket.
Markdown is supported
0%
or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment