Введение

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

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

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

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

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

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

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

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

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

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

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

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

События ALV Grid

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

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

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

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

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

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

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

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