Меню

MVC и обработка событий

Надеюсь, тебя заинтересовала моя предыдущая статья по MVC на ABAP и ты попробовал с ее помощью реализовать свой очередной отчет. Но подожди, скажешь ты, нам редко нужен вывод информации с помощью, например, ALV Table без какого-либо взаимодействия с пользователем. И конечно же, ты прав! Поэтому рекомендую тебе прочесть статью номер два.

Введение

Привет, коллега!

Надеюсь, тебя заинтересовала моя предыдущая статья по MVC на ABAP и ты попробовал с ее помощью реализовать свой очередной отчет. Но подожди, скажешь ты, нам редко нужен вывод информации с помощью, например, ALV Table без какого-либо взаимодействия с пользователем. И конечно же, ты прав! Поэтому рекомендую тебе прочесть статью номер два.

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

Изменение концепции архитектуры

В первой реализации, как ты помнишь, контроллер сам создавал модель и представление внутри себя. Таким образом, получалось, что контроллер может работать только с теми экземплярами классов, которые он же сам и создал. Это в некотором роде «убивает» гибкость.

Предлагаю избавиться от этого ограничения и вынести создание объектов классов lcl_model и lcl_view за предел контроллера. Но  как же тогда контроллер узнает о том, какую модель и какое представление ему использовать? Очень просто - мы их будем передавать во время создания объекта контроллера, прямо в конструктор. И там их будем запоминать в качестве атрибутов класса.

Класс контроллера

* Добавляем контроллеру входные параметры модели и представления

 

Основная программа


Такой способ создания объектов с их последующей передачей был подсмотрен мной в реализациях MVC на Java.

Возможно, ты заметил еще один плюс от нового способа реализации... Взгляни еще раз на то, как мы стали передавать данные с селекционного экрана! Да-да, нам больше не надо протаскивать их через контроллер, который с ними и так ничего не делал. Теперь мы их передаем напрямую в модель. Причем, если бы у нас были параметры, связанные только с отображением (например, вариант layout'а ALV Grid'а), мы бы их так же передали представлению напрямую. Без посредника в виде контроллера.

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

События ALV Grid

Наш следующий этап использования MVC - это обработка действий пользователя с ALV Grid'ом. Предлагаю рассмотреть его на примере проваливания (drilldown) по номеру единицы оборудования в стандартную транзакцию просмотра IE03.

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

Первый вариант - мы можем жестко повесить методы контроллера на события экземпляра ALV Grid'а. Но в таком случае, контроллер будет знать, какой именно объект используется для вывода информации на экран. А также нам придется делать этот объект доступным извне, что не есть хорошо.

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

Поэтому я выбрал третий путь - создание интерфейсов для взаимодействия объектов между собой.

Создание интерфейса взаимодействия

Чтобы реализовать третий вариант, объявляем новый интерфейс с единственным методом.

Интерфейс взаимодействия представления с контроллером

Если хотите прочитать статью полностью и оставить свои комментарии присоединяйтесь к sapland

У вас уже есть учетная запись?

Войти

Обсуждения Количество комментариев7

Комментарий от  

Михаил Короченков

  |  11 октября 2017, 15:33

И вновь, Иван, лайк конечно за популизацию либомого мной стиля MVC в ABAPe.
Но прежде чем писать статьи такие наберитесь опыта в данном стиле ибо как пастырь поведете народ к полу-индусскому коду(не похоже что вы в таком стиле создавали действительно крупные Z-ки со множеством экранов, подэкранов и событий).
Вот вам задача на дом: если у вас будет во вью 100-ня событий обрабатываемых, будете 100 методов на каждое событие в интерфейсе создавать?!

Комментарий от  

Валерий Заузолков

  |  18 июня 2018, 15:52

И вновь, Иван, лайк конечно за популизацию либомого мной стиля MVC в ABAPe.
Но прежде чем писать статьи такие наберитесь опыта в данном стиле ибо как пастырь поведете народ к полу-индусскому коду(не похоже что вы в таком стиле создавали действительно крупные Z-ки со множеством экранов, подэкранов и событий).
Вот вам задача на дом: если у вас будет во вью 100-ня событий обрабатываемых, будете 100 методов на каждое событие в интерфейсе создавать?!

Кроме критики хотелось бы глянуть на то, что предлагаете Вы.

Комментарий от  

Антон Китаев

  |  09 июня 2019, 20:51

Кроме критики хотелось бы глянуть на то, что предлагаете Вы.

А что тут предлагать, если человек декларирует handler-ы в интерфейсе? Замечание Михаила вполне уместно и не требует никаких пояснений.

Комментарий от  

Александр Носов

  |  04 августа 2020, 16:24

Связь между контроллером и представлением можно ослабить:
1. В контроллер передавать интерфейс представления.
2. Интерфейс представления должен содержать: метод для отображения представления; события взаимодействий с пользователем; контекст (часть модели для отображения).
3. В контроллере нужно реализовать события представления.
4. В конструкторе контроллера нужно подписаться на события представления и связать модель с контекстом представления.

Комментарий от  

Михаил Колбин

  |  04 декабря 2020, 12:09

Связь между контроллером и представлением можно ослабить:
1. В контроллер передавать интерфейс представления.
2. Интерфейс представления должен содержать: метод для отображения представления; события взаимодействий с пользователем; контекст (часть модели для отображения).
3. В контроллере нужно реализовать события представления.
4. В конструкторе контроллера нужно подписаться на события представления и связать модель с контекстом представления.

Вот бы пример такой посмотреть...

Комментарий от  

Александр Носов

  |  04 декабря 2020, 12:14

Вот бы пример такой посмотреть...

Комментарий от  

Михаил Колбин

  |  04 декабря 2020, 18:22