Добавил:

ivanov666 Опубликованный материал нарушает ваши авторские права? Сообщите нам.

Вуз:

Башкирский Государственный Аграрный Университет

Предмет:

[НЕСОРТИРОВАННОЕ]

Файл:

Проектирование информационных систем. Учебное пособие

.pdf

Скачиваний:

Добавлен:

07.09.2026

Размер:

1 Мб

Скачать

☆

<<< < Предыдущая 1 23 / 73 4 5 6 7 > Следующая >>>

Рис. 2.3. Архитектура CQRS

2) Command Handler – это компонент, который получает Command

и выполняет операцию записи в системе. Command Handler получает данные из Command и передает их в Write Model для сохранения изменений в базе данных;

3) Write Model – это модель данных, которая используется для операций записи в системе. Write Model содержит данные, необходимые для сохранения изменений в базе данных;

4) Event – это объект, произошедших в системе после выполнения операции записи. Event может быть отправлен в другие части системы, которые могут быть заинтересованы в этих изменениях.

Компоненты чтения :

1) Read Model – это модель данных, предназначенная для чтения. Read Model содержит только те данные, которые нужны для отображе-

ния пользователю или для выполнения запросов, она тимизирована для конкретных запросов, что позволяет повысить производительность системы;

2) Event Handler – это компонент, который получает Event и обновляет данные в Read Model в соответствии с изменениями, произошедшими в системе. Event Handler получает данные из Event и обновляет

Read Model, чтобы отобразить эти изменения;

3) Query – это объект, который содержит данные, необходимые для

выполнения любой части системы, например из веб-приложения;

операции чтения в системе; он может быть отправлен из

который содержит данные об изменениях,

может быть оп-

4) Query Handler – это компонент, который получает Query и воз-

вращает данные из Read Model в соответствии с запросом. Он получает данные из Read Model и возвращает их в виде списка или другого формата, который может быть использован для отображения данных пользователю или для выполнения запросов на чтение.

Применение CQRS может быть особенно полезным в системах с большим количеством операций записи или при необходимости распределенной обработки запросов. CQRS также может облегчить сопровождение приложения, поскольку изменения в одной части системы не будут влиять на другие части.

Таким образом, шаблон CQRS целесообразно применять в следующих случаях:

1) при использовании событийной модели данных, когда записы-

ваются события в системе

, а любые чтения подразумевают проекцию

событий в отчет;

2) применении асинхронной модели записи данных;

3) чтении данных, требующих много времени на выгрузку и обра-

ботку;

4) наличии различных клиентов со специфическими требованиями

к данным.

Внедрение подхода CQRS может повысить производительность, масштабируемость и безопасность системы. Это объясняется тем, что гибкость, создаваемая переходом

на CQRS, позволяет системе лучше развиваться с течением времени и не позволяет командам обновления вызывать конфликты слияния на уровне домена. Несмотря на это, применение рассматриваемого подхода требует дополнительных усилий по разработке и поддержке системы [6].

2.4. ШАБЛОНЫ ПРОЕКТИРОВАНИЯ MVC,

MVP, MVVM, MVI

2.4.1. Шаблон проектирования «Модель – Представление – Контроллер» (MVC)

Существует несколько архитектурных шаблонов на основе выделенной модели. Одним из них является «Модель – Представление – Контроллер» (Model-View-Controller, MVC). Основная идея шаблона проектирования MVC состоит в том, что функциональность каждого

пользовательского сценария разбивается на три части – модель, представление и контроллер. Модель в этом случае представляет собой то место, где реализуется вся бизнес-логика, определяются бизнеспроцессы, происходит взаимодействие с уровнем доступа к данным и др. Кроме того, модель, как правило, определяет все базовые сущности, с которыми впоследствии оперируют остальные тура на основе подхода MVC показана на рис. 2.4.

уровни. Архитек-

Рис. 2.4. Архитектура MVC

Уровень представления в этой схеме играет также важную роль, поскольку он отвечает за генерацию пользовательского интерфейса (код HTML). На этом уровне не выполняется никаких бизнес-операций, а просто принимаются решения о том, каким образом генерировать представление пользовательского интерфейса. При этом уровень представления использует данные, которые поступают от модели.

Контроллер ет пользовательский ввод и принимает решение о том, какое именно представление использовать в настоящий момент, а также передает ему данные, полученные от модели.

Запрос от клиента передается соответствующему контроллеру. Контроллер определяется в соответствии с таблицей маршрутов приложения. Далее контроллер на основе полученной информации о за просе выполняет все необходимые взаимодействия с моделью: выбирает представление, которое будет использоваться, и передает управление этому представлению; представлению передаются необходимые данные, полученные от модели.

является связующим звеном – фактически обрабатыва-

Такое разделение программного кода позволяет добиться нескольких положительных эффектов, которые получаются из-за четкого разделения ответственности между объектами:

1) становится возможным работать с моделью и тестировать модель

независимо от представления и других частей приложения;

2) все остальные компоненты приложения также остаются незави-

симыми;

3) появляется возможность подменять представления теми

, которые

необходимы в настоящий момент, не затрагивая при этом код модели или контроллеров. Например, в различных ситуациях можно генерировать HTML-представление или RSS-представление одних и тех же данных, поступающих от модели.

Конечное преимущество кода с разделением ответственности сводится к более низкой связности компонентов системы, что с точки зрения практики разработки приложения является показателем более высококачественного программного кода. Таким образом, процесс обработки запроса в приложении на базе шаблона MVC протекает следующим образом:

1) поступает запрос от клиента;

2) на основании таблицы маршрутов выбирается первый подходя-

щий для этого адреса маршрут;

3) на основе выбранного маршрута выбирается необходимый

кон-

троллер, который будет заниматься обработкой этого запроса;

4) на основе запроса внутри контроллера выбирается действие (ме-

тод класса), которое должно быть выполнено;

5) при выполнении действия контроллера обрабатывается пользо-

вательский ввод и другие параметры, которые влияют на функционирование приложения, выбирается представление и генерируются данные для него; на

этом этапе также может осуществляться работа с мо-

делью;

6) представление на основе полученных данных генерирует содер-

жимое, которое будет отправлено клиенту (как правило, код HTML);

7) полученное содержимое передается клиенту, и жизненный цикл

запроса прекращается.

Главная идея шаблона MVC – повторное использование кода и разделение проблем. Предположим, что веб-приложение состоит из

не-

скольких подприложений:

1) frontend – часть сайта, которую видят обычные пользователи;

2) backend – административная часть сайта, позволяющая управ-

лять приложением, доступ к ней обычно ограничен;

3) консоль – приложение, состоящее из набора консольных команд,

запускаемых в окне терминала вручную или по расписанию;

4) API – часть приложения, которая предоставляет сторонним при-

ложениям интерфейсы для интеграции с ним.

Данные подприложения могут быть реализованы в виде модулей или как приложение, которое содержит код, общий для нескольких подприложений.

Модели представляют внутреннюю структуру данных приложения. Они часто являются общими для нескольких подприложений. Например, модель LoginForm может быть использована как в пользовательской, так и в административной части приложения. Модель News может применяться консольными командами, API и front/back-частями приложения. Поэтому модели

должны содержать свойства, представляющие конкретные данные; должны включать в себя бизнес-логику (например, правила валидации), чтобы убедиться в том, что данные соответствуют предъявленным требованиям; могут содержать код для работы с данными.

Представления отвечают за отображение моделей в необходимом пользователю формате. В общем случае ключевые особенности представлений могут быть

описаны следующим образом:

1) представления должны содержать разметку, такую как HTML, и простой PHP-код, используемый для обхода, форматирования и отображения данных;

2) представления не должны напрямую обращаться к базе данных, этим должны заниматься модели;

3) представления не должны напрямую обращаться к $_GET, $_POST и другим переменным, получаемым из запроса пользователя.

Эту задачу

должен выполнять контроллер. Представления должны использоваться только для оформления данных, полученных от контроллера и модели;

4) представления могут напрямую обращаться к свойствам и мето- дам контроллера или моделей, однако это должно делаться только для отображения данных;

5) представления можно использовать повторно несколькими спо- собами: с помощью общего шаблона (в

него можно вынести разметку,

общую для всех страниц, например шапку и подвал); части шаблона

(используются внутри других шаблонов и, как правило, не использу-

ются с общим шаблоном. Например, часть шаблона _form.php можно использовать для отображения формы ввода модели, которая будет применяться как при ее создании, так и при редактировании).

Контроллеры – это связующее звено, соединяющее модели, представления и другие компоненты в одно рабочее приложение. Контроллеры отвечают за обработку запросов пользователя, поэтому они обладают следующими свойствами:

1) могут обращаться к $_GET, $_POST и другим переменным PHP,

получаемым из запроса пользователя;

2) могут создавать экземпляры моделей и управлять ими;

3) не должны содержать SQL-запросы, их лучше держать в моделях;

4) не должны содержать разметку, ее стоит вынести в представления

2.4.2. Шаблон проектирования «Модель – Представление – Ведущий» (MVP)

Шаблон проектирования «Модель – Представление – Ведущий»

(Model-View-Presenter, MVP) – это популярный архитектурный шаблон

для разработки программного обеспечения, который используется для построения приложений. MVP разделяет приложение на три основных компонента, описанных ниже.

1. Модель (Model) представляет собой бизнес-логику приложения и данные. Она ответственна за выполнение операций, таких как чтение и

запись данных, обработка бизнес-логики и взаимодействие с базой данных или внешними источниками данных. Модель не зависит от представления или ведущего и предоставляет API для доступа к данным.

2. Представление (View) отображает данные пользователю и обрабатывает пользовательский ввод, т. е. представляет собой интерфейс пользователя, через который он взаимодействует с приложением. В MVP

представление пассивно и не содержит бизнес-логики, а лишь отображает данные, предоставленные ведущим, и передает ему пользовательский ввод.

3. Ведущий (Presenter) является посредником между моделью и представлением. Он содержит бизнес-логику приложения и управляет взаимодействием между моделью и представлением. Ведущий получает данные от модели, форматирует их и передает представлению

для отображения. Он также обрабатывает пользовательский ввод, передавая соответствующие команды модели для обновления данных.

Основная идея MVP заключается в разделении ответственности между компонентами таким образом, чтобы изменения в одном компоненте не влияли на другие. Это позволяет легче тестировать компоненты независимо друг от друга. MVP также способствует более четкому разделению бизнес лее понятным и масштабируемым. Архитектура на основе подхода

MVP показана на рис. 2.5.

-логики и отображения данных, что делает код бо-

Рис. 2.5. Архитектура MVP

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

1) шаблон может быть избыточно сложным для простых проектов;

2) повышенная сложность по сравнению с традиционным

за дополнительных обязанностей ведущего;

3) возможные издержки связи между компонентами.

Ключевые отличия шаблонов MVC и MVP основаны на способе организации компонентов приложения. В качестве основных критериев сравнения этих подходов можно использовать следующие характеристики: распределение ответственности, взаимосвязь компонентов и особенности тестирования приложения. Результаты сравнения приведены в таблице ниже.

MVC из-

Результаты сравнительного анализа шаблонов MVC и MVP

Критерий

сравнения

Распределение ответственности

Взаимосвязь компонентов

Тестирование Тестирование контроллера

Модель (Model) представляет бизнес-логику и данные. Представление (View) отвечает за отображение данных и обработку пользовательского ввода. Контроллер (Controller) управляет взаимодействием между моделью и представлением, обрабатывает пользовательский ввод и принимает решения о том, какие данные должны быть показаны в представлении

Представление (View) обычно зависит от контроллера (Controller) и обновляется контроллером при изменении данных модели (Model). Контроллер (Controller) может непосредственно взаимодействовать с представлением (View) для обновления его состояния

(Controller) может быть сложным из-за его прямой связи с представлением

(View).

Юнит-тестирование представления (View) может быть сложным

Шаблон MVC Шаблон MVP

Модель (Model) также представляет ные. Представление (View) пассивно отображает данные и передает пользовательский ввод ведущему. Ведущий (Presenter) берет на себя большую часть бизнеслогики и управления представлением. Он является посредником между моделью и представлением и принимает решения о том, какие данные должны быть отображены в представлении

Представление (View) пассивно отображает данные и не зависит напрямую от ведущего (Presenter). Оно обновляется ведущим. Ведущий (Presenter) полностью управляет представлением и не имеет прямой зависимости от него

Ведущий (Presenter) легко подвергается юнит-тестированию, так как он не имеет прямой связи с фактическим представлением (View). Представление (View) может быть протестировано как отдельно, так и с заменой ведущего на фиктивный (mock) объект для тестирования

бизнес-логику и дан-

2.4.3. Шаблон проектирования «Модель – Представление –

ViewModel» (MVVM)

Шаблон проектирования «Модель – Представление – ViewModel» (Model-View-ViewModel, MVVM) был представлен как ответ на огра-

ничения шаблона MVP с целью упрощения разработки пользовательского интерфейса. MVVM – это эволюция шаблона MVP, ориентированная на разделение задач и повышение тестируемости. Шаблон

MVVM состоит из трех ключевых компонентов.

1. Модель (Model) представляет собой данные и бизнес-логику

приложения ботку любых необходимых данных.

2. Представление (View) служит пользовательским интерфейсом и отображает данные пользователю. В MVVM представление обычно разрабатывается с использованием языка разметки, такого как XAML, который позволяет четко разделить дизайн пользовательского интерфейса и код программной части.

3. ViewModel является посредником между моделью и нием, отвечает за сохранение состояния представления и выполнение любых операций, необходимых для преобразования данных внутри модели в формат, удобный для представления. ViewModel обеспечивает привязку данных между моделью и представлением с помощью команд и событий.

В этом шаблоне, так же как и в других на основе выделенной модели, присутствует модель (Model), и логику, представление (View), с которым взаимодействует пользователь, и ViewModel – промежуточный слой между представлением и моделью. Отличительной особенностью этого шаблона является механизм взаимодействия представления и ViewModel, он осуществляется за счет процесса связывания данных между приложением и бизнеслогикой. Таким образом, связь между представлением и ViewModel осуществляет сам метки. Архитектура MVVM показана на рис. 2.6.

, отвечает за получение и хранение данных, а также обра-

представле-

содержащая в себе бизнес-данные

фреймворк на основе статической информации раз-

Рис. 2.6. Архитектура MVVM

В шаблоне MVVM ViewModel не содержит прямых ссылок на View. Вместо этого взаимодействие с представлением происходит посредством привязки данных и команд. Такое разделение задач позволяет упростить тестирование и лучше отделить логику, связанную с пользовательским интерфейсом, от базовой бизнес-логики. MVVM особенно хорошо подходит для разработки сложных приложений пользовательского интерфейса, где требуется обширная

привязка данных, а также для проектов, использующих такие платформы, как WPF, UWP, Angular и Xamarin.Forms.

2.4.4. Шаблон проектирования «Модель – Представление – Намерение» (MVI)

Шаблон проектирования «Модель – Представление – Намерение»

(Model-View-Intent, MVI) – это подход, основанный на идеях потоков

данных и реактивного программирования, он активно используется в мобильной разработке. В шаблоне содержатся три основных компонента.

1. Модель (Model), которая отвечает за

бизнес-логику и данные,

а также хранит текущее состояние (state) системы.

2. Представление (View), которое отвечает за отображение состоя-

ний (states) системы и выдачу намерений (Intent).

3. Намерения (Intent) – это действия пользователя или события, ко-

торые генерируют новые изменения в состоянии. Намерение (Intent) передается в модель (Model) для обработки и изменения ее состояния.

Отличие MVI от других шаблонов

заключается в том, что, совершая действие по изменению модели в представлении, пользователь отправляет намерение в систему. Это намерение обновляет модель, с которой связано представление, в результате чего представление получает информацию об изменении модели и перерисовывает ее. Архитектура на основе подхода MVI показана на рис. 2.7.

Преимуществами подхода MVI являются

следующие.

1. Простота управления состоянием. Подход MVI предлагает чет-

кую и понятную модель управления состояниями приложения.

2. Однозначность потоков данных. Все данные передаются в одном

направлении, что исключает случайные ошибки при обработке событий.

3. Реактивная природа. Подходит для асинхронных операций и ре-

активного программирования.

<<< < Предыдущая 1 23 / 73 4 5 6 7 > Следующая >>>

Соседние файлы в предмете [НЕСОРТИРОВАННОЕ]