[ERP-системы] Реализация MVVM в ABAP
Автор
Сообщение
news_bot ®
Стаж: 6 лет 4 месяца
Сообщений: 27286
После окончания университета я несколько лет работал программистом C#. Я разрабатывал приложения на WPF с использованием шаблона проектирования MVVM. Затем перешел на ABAP. К большому удивлению обнаружил что ABAP является скорее процедурным языком чем объектно-ориентированным, хотя SAP прилагает большие усилия для продвижения ОО-парадигмы. Для разделения бизнес-логики от GUI как правило используют архитектурный шаблон MVC. Пытаясь реализовать MVC шаблон я каждый раз сталкивался с определенными сложностями, которые делают поддержку программы еще более сложной чем если бы она была написана на процедурах. Не смотря на то, что реализация MVC подробно и с примерами описана в книге Design Patterns in ABAP Objects и на специализированных ресурсах (sapland.ru, blogs.sap.com и др.), проблемы с разделением логики остаются. В реализации MVC на ABAP независимой частью остается Model, а View и Controller тесно связаны между собой. Сильное сопряжение между View и Controller затрудняет поддержку и масштабируемость. Ниже описано почему так происходит и что с этим делать.
Шаблоны MVC и MVVM
Подробно описывать принцип работы шаблонов MVC и MVVM в данной статье я не буду. Приведу лишь основные моменты, которые понадобятся нам в дальнейшем.
Основное отличие MVC от MVVM в том, что в первой Controller знает как View, так и Model, также допускается что View будет знать о Model.
![Клик для увеличения](https://linkme.ufanet.ru/box/200x100/1234091eb7c89cf1fbf9cc7f0ace2fe7.png)
В MVVM шаблоне связь между слоями более слабая. View знает только ViewModel, а ViewModel только Model. View получает данные от ViewModel через ссылку на DataContex.
![Клик для увеличения](https://linkme.ufanet.ru/box/200x100/95c2df521b3f21b724ca28b45a3ebe18.png)
Шаблон MVVM предназначен для разработки в WPF на языке C#. Но его идею можно применять и в ABAP.
Проблемы MVC в ABAP
При реализации MVC, как правило, классы Model выносят в глобальное определение, а классы View и Controller в локальное. Использование локальных классов обусловлено необходимостью взаимодействия с GUI элементами. Дело в том, что на ABAP-классах нельзя построить полноценный GUI. В классах View можно использовать функционал для формирования GUI (CL_SALV_TABLE, REUSE_ALV_GRID_DISPLAY и т.п.), но этого не достаточно. Создать GUI-статусы, заголовки, экраны, PBO, PAI в классе невозможно.
Локальные View и Controller, имеют ряд недостатков:
- View и Controller имеют доступ ко всем глобальным переменным и параметрам экрана выбора.
- Обработка PBO и PAI в Controller требует получения состояния View (например получение выделенных строк ALV) или обновление View (например обновление таблицы ALV). В качестве решения данной проблемы нередко можно увидеть публичные атрибуты View, на которые воздействует Controller, или когда View имеет ссылку на Controller. Оба решения плохие, т.к. в первом случае нарушается инкапсуляция, а во втором Low Coupling.
MVVM в ABAP или MVA
Желая использовать преимущества MVVM в ABAP и сделать слои более независимыми я определил для себя следующий шаблон разработки.
![Клик для увеличения](https://linkme.ufanet.ru/box/200x100/6d4f74f74e0f1715c475ff05b69c4933.png)
Так как в чистом виде MVVM реализовать на ABAP нельзя, то ViewModel использовать не совсем корректно. Поэтому вместо ViewModel и Controller я использую Application.
Принцип разделения логики аналогичен принципу MVVM. View передает команды пользователя в Application, а Application воздействует на модель. Обратная связь при этом отсутствует.
Особенностью ABAP приложений является то, то представление может обновиться только после действий пользователя. Даже если какой-нибудь асинхронный процесс поменяет модель, то инициировать обновление представление он не сможет. Данная особенность позволяет ослабить связь модель-представление и делегировать функцию обновления представления самому представлению. Иными словами, представление само должно решать, когда надо обновить себя, а когда нет.
Концепция MVA
Реализация MVA основана на объектно-ориентированном подходе, где на каждый слой архитектуры будет реализован один или несколько классов. Каждый из слоев обладает рядом свойств.
Представление (View и IView):
- MVA работает с абстракцией представления IView. Все классы View должны содержать реализацию IView.
- IView содержит события, которые требуют взаимодействия с моделью
- IView содержит контекст — ссылка на данные модели, которые необходимо отобразить пользователю
- View может содержать бизнес-логику, которая не требует взаимодействия с моделью. Например, если требуется реализовать из ALV проваливание в карточку контрагента, то данная логика будет относиться к представлению.
- View содержит GUI элементы в группе функций, которая связана с классом View.
Приложение (Application):
- Выполняет роль связки представления и модели и является точкой входа в приложение.
- Имеет критерии запуска — набор параметров, которые определяют с какими параметрами необходимо запустить приложение. Обычно это параметры селекционного экрана.
- Критерии приложения состоят из критериев модели и представления. Например, если на селекционном экране требуется ввести дату проводки и указать флаг вывода отчета PDF или ALV, то дата проводки будет относиться к критериям модели, а флаг PDF и ALV к критериям представления.
- В конструктор приложения передаются критерии запуска. Приложение создает модель и представление, подписывается на события представления, связывает контекст представления с моделью.
Модель (Model):
- Содержит публичные атрибуты, которые необходимы представлению.
- Содержит критерии расчета модели и метод инициализации.
Реализация MVA
Рассмотрим реализацию MVA на примере отчета по движению материалов. В качестве взаимодействия с моделью будет кнопка обновления данных.
Диаграмма классов будет выглядеть следующим образом.
![Клик для увеличения](https://linkme.ufanet.ru/box/200x100/186b35559371ebdb35b1c22ec57660df.png)
Model. Конструктор модели будет принимать на входи критерии выбора данных. Класс будет иметь методы инициализации и обновления данных, а также атрибут с данными для отображения.
![Клик для увеличения](https://linkme.ufanet.ru/box/200x100/531a534c155188c8ad8e2408d497b274.png)
![Клик для увеличения](https://linkme.ufanet.ru/box/200x100/dfb78eb3a972cb0ac788a1a3311d104b.png)
![Клик для увеличения](https://linkme.ufanet.ru/box/200x100/4d3055c39d639a1bf9d3c832c73e79ac.png)
IView. Интерфейс представления содержит методы установки контекста, отображения представления, события и определение типов контекста.
![Клик для увеличения](https://linkme.ufanet.ru/box/200x100/7ee46609c1ef7b89beaab2ee0aaa22da.png)
![Клик для увеличения](https://linkme.ufanet.ru/box/200x100/4fda303227e77beec64b72568fe5d9c8.png)
![Клик для увеличения](https://linkme.ufanet.ru/box/200x100/507615deea73ad16bd8c93195591ba50.png)
IView содержит в себе описание структуры контекста, причем поля структуры должны быть ссылочными
![Клик для увеличения](https://linkme.ufanet.ru/box/200x100/196bfc34c2c0cc6b76845b7f28c2a613.png)
View. Представление реализует интерфейс IView. Причем все события пользователя регистрирует класс View и вызывает только те события, которые нужно обработать приложению. В параметрах событий необходимо передать все данные, которые нужны от View (например, выделенные строки ALV).
Реализация класса View в ALV представлении
![Клик для увеличения](https://linkme.ufanet.ru/box/200x100/24ec880212e1b170f4ee34c0b3eb3ec2.png)
В данной реализации нам необходимо определение GUI статуса, для этого создадим ФМ и свяжем его с экземпляром CL_SALV_TABLE
![Клик для увеличения](https://linkme.ufanet.ru/box/200x100/270a01acabb186aed19a55b538908cbd.png)
Важно что все UI события принимает View (в данном случае через ON_USER_COMMAND) и при необходимости View делает RAISE EVENT для Application. Этот подход делает View и Application более независимыми.
Application. Конструктор приложения принимает на вход критерии приложения (параметры экрана выбора) и создает экземпляры Model и View, подписывается на события View и связывает контекст View с Model. Конструктор — это единственное место где приложение знает о View. Application содержит метод RUN, который запускает программу. Запуск приложения можно сравнить с запуском транзакции с заранее определенными параметрами экрана. Это позволяет использовать ее из других программ без SUBMIT.
![Клик для увеличения](https://linkme.ufanet.ru/box/200x100/65e093dbdfbd28c7be350911b9915807.png)
Запуск Application. Теперь делаем программу, которая будет запускать приложение.
![Клик для увеличения](https://linkme.ufanet.ru/box/200x100/76cfab6cba8e51f7a132fcf69e339f95.png)
Все, приложение готово. Можно смотреть результат.
![Клик для увеличения](https://linkme.ufanet.ru/box/200x100/e3d468f714600d241d3a53bff8149e25.png)
Бизнес-логика на стороне View. Обработку событий, которые не требуют обращения к модели и контроллеру, можно делать в самой View.
Например, если требуется реализовать открытие MM03 при двойном клике на MATNR, то обработку данной логики можно сделать на стороне View.
![Клик для увеличения](https://linkme.ufanet.ru/box/200x100/24d68c8f7558664dc1dbe9eb8bddfecd.png)
На уровень View данная логика вынесена исходя из соображений: к модели не требуется обращаться за дополнительными данными; логика относится только к ALV, т.е. если бы была реализация View в виде Excel или PDF, то данное событие невозможно было бы обработать.
Литература
Design Patterns in ABAP Objects
Паттерны для новичков: MVC vs MVP vs MVVM
Архитектурные шаблоны в ABAP: MVC, MVP, MVVM, MVA
===========
Источник:
habr.com
===========
Похожие новости:
- [Разработка систем связи, Growth Hacking, Монетизация мобильных приложений, Аналитика мобильных приложений, Голосовые интерфейсы] Объединяем закрытый WhatsApp и открытый SIP – Часть 1
- [IT-инфраструктура, ERP-системы, CRM-системы, Управление проектами, Управление продуктом] Новый формат отдела разработки ПО
- [Аналитика мобильных приложений, Лайфхаки для гиков] Как избежать блокировки в WhatsApp для того чтобы… (перевод)
- [ERP-системы] Зачем в ABAP нужен оператор SET UPDATE TASK LOCAL
- [Поисковые технологии, Программирование, Java, Разработка под e-commerce] Кому рецепты для электронной коммерции? Для SAP Commerce и не только
- [Разработка веб-сайтов, PHP, Проектирование и рефакторинг] Сущности (entities) и сервисы (services) как основа распределенной логики для MVC шаблона проектирования
- [.NET, ASP, Microsoft SQL Server, API, C#] ASP.NET Core MVC: WebAPI + Entity Framework + Microsoft SQL Server + Angular
- [IT-инфраструктура, API, ERP-системы, Софт] Интеграция в системах контроля доступа
- [ERP-системы, Финансы в IT] Автоматизация бюджетирования: что это, с какими проблемами связано и какие программные продукты использует?
- [ERP-системы, Управление проектами] Управление требованиями и сроками в методологии Oracle AIM BF
Теги для поиска: #_erpsistemy (ERP-системы), #_sap, #_abap, #_mvc, #_mvvm, #_mva, #_erpsistemy (
ERP-системы
)
Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы
Текущее время: 06-Июл 23:18
Часовой пояс: UTC + 5
Автор | Сообщение |
---|---|
news_bot ®
Стаж: 6 лет 4 месяца |
|
После окончания университета я несколько лет работал программистом C#. Я разрабатывал приложения на WPF с использованием шаблона проектирования MVVM. Затем перешел на ABAP. К большому удивлению обнаружил что ABAP является скорее процедурным языком чем объектно-ориентированным, хотя SAP прилагает большие усилия для продвижения ОО-парадигмы. Для разделения бизнес-логики от GUI как правило используют архитектурный шаблон MVC. Пытаясь реализовать MVC шаблон я каждый раз сталкивался с определенными сложностями, которые делают поддержку программы еще более сложной чем если бы она была написана на процедурах. Не смотря на то, что реализация MVC подробно и с примерами описана в книге Design Patterns in ABAP Objects и на специализированных ресурсах (sapland.ru, blogs.sap.com и др.), проблемы с разделением логики остаются. В реализации MVC на ABAP независимой частью остается Model, а View и Controller тесно связаны между собой. Сильное сопряжение между View и Controller затрудняет поддержку и масштабируемость. Ниже описано почему так происходит и что с этим делать. Шаблоны MVC и MVVM Подробно описывать принцип работы шаблонов MVC и MVVM в данной статье я не буду. Приведу лишь основные моменты, которые понадобятся нам в дальнейшем. Основное отличие MVC от MVVM в том, что в первой Controller знает как View, так и Model, также допускается что View будет знать о Model. ![]() В MVVM шаблоне связь между слоями более слабая. View знает только ViewModel, а ViewModel только Model. View получает данные от ViewModel через ссылку на DataContex. ![]() Шаблон MVVM предназначен для разработки в WPF на языке C#. Но его идею можно применять и в ABAP. Проблемы MVC в ABAP При реализации MVC, как правило, классы Model выносят в глобальное определение, а классы View и Controller в локальное. Использование локальных классов обусловлено необходимостью взаимодействия с GUI элементами. Дело в том, что на ABAP-классах нельзя построить полноценный GUI. В классах View можно использовать функционал для формирования GUI (CL_SALV_TABLE, REUSE_ALV_GRID_DISPLAY и т.п.), но этого не достаточно. Создать GUI-статусы, заголовки, экраны, PBO, PAI в классе невозможно. Локальные View и Controller, имеют ряд недостатков:
MVVM в ABAP или MVA Желая использовать преимущества MVVM в ABAP и сделать слои более независимыми я определил для себя следующий шаблон разработки. ![]() Так как в чистом виде MVVM реализовать на ABAP нельзя, то ViewModel использовать не совсем корректно. Поэтому вместо ViewModel и Controller я использую Application. Принцип разделения логики аналогичен принципу MVVM. View передает команды пользователя в Application, а Application воздействует на модель. Обратная связь при этом отсутствует. Особенностью ABAP приложений является то, то представление может обновиться только после действий пользователя. Даже если какой-нибудь асинхронный процесс поменяет модель, то инициировать обновление представление он не сможет. Данная особенность позволяет ослабить связь модель-представление и делегировать функцию обновления представления самому представлению. Иными словами, представление само должно решать, когда надо обновить себя, а когда нет. Концепция MVA Реализация MVA основана на объектно-ориентированном подходе, где на каждый слой архитектуры будет реализован один или несколько классов. Каждый из слоев обладает рядом свойств. Представление (View и IView):
Приложение (Application):
Модель (Model):
Реализация MVA Рассмотрим реализацию MVA на примере отчета по движению материалов. В качестве взаимодействия с моделью будет кнопка обновления данных. Диаграмма классов будет выглядеть следующим образом. ![]() Model. Конструктор модели будет принимать на входи критерии выбора данных. Класс будет иметь методы инициализации и обновления данных, а также атрибут с данными для отображения. ![]() ![]() ![]() IView. Интерфейс представления содержит методы установки контекста, отображения представления, события и определение типов контекста. ![]() ![]() ![]() IView содержит в себе описание структуры контекста, причем поля структуры должны быть ссылочными ![]() View. Представление реализует интерфейс IView. Причем все события пользователя регистрирует класс View и вызывает только те события, которые нужно обработать приложению. В параметрах событий необходимо передать все данные, которые нужны от View (например, выделенные строки ALV). Реализация класса View в ALV представлении ![]() В данной реализации нам необходимо определение GUI статуса, для этого создадим ФМ и свяжем его с экземпляром CL_SALV_TABLE ![]() Важно что все UI события принимает View (в данном случае через ON_USER_COMMAND) и при необходимости View делает RAISE EVENT для Application. Этот подход делает View и Application более независимыми. Application. Конструктор приложения принимает на вход критерии приложения (параметры экрана выбора) и создает экземпляры Model и View, подписывается на события View и связывает контекст View с Model. Конструктор — это единственное место где приложение знает о View. Application содержит метод RUN, который запускает программу. Запуск приложения можно сравнить с запуском транзакции с заранее определенными параметрами экрана. Это позволяет использовать ее из других программ без SUBMIT. ![]() Запуск Application. Теперь делаем программу, которая будет запускать приложение. ![]() Все, приложение готово. Можно смотреть результат. ![]() Бизнес-логика на стороне View. Обработку событий, которые не требуют обращения к модели и контроллеру, можно делать в самой View. Например, если требуется реализовать открытие MM03 при двойном клике на MATNR, то обработку данной логики можно сделать на стороне View. ![]() На уровень View данная логика вынесена исходя из соображений: к модели не требуется обращаться за дополнительными данными; логика относится только к ALV, т.е. если бы была реализация View в виде Excel или PDF, то данное событие невозможно было бы обработать. Литература Design Patterns in ABAP Objects Паттерны для новичков: MVC vs MVP vs MVVM Архитектурные шаблоны в ABAP: MVC, MVP, MVVM, MVA =========== Источник: habr.com =========== Похожие новости:
ERP-системы ) |
|
Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы
Текущее время: 06-Июл 23:18
Часовой пояс: UTC + 5