Привет, коллега!
Надеюсь, тебя заинтересовала моя предыдущая статья по MVC на ABAP и ты попробовал с ее помощью реализовать свой очередной отчет. Но подожди, скажешь ты, нам редко нужен вывод информации с помощью, например, ALV Table без какого-либо взаимодействия с пользователем. И конечно же, ты прав! Поэтому рекомендую тебе прочесть статью номер два.
Итак, сегодня мы рассмотрим, каким же образом обрабатывать события, происходящие с нашей табличкой. Предлагаю рассмотреть их на основе ПО, с которым можно было познакомиться в первой статье. Однако, мы немного изменим подход к созданию модели и представления. Но давайте обо всем по порядку.
В первой реализации, как ты помнишь, контроллер сам создавал модель и представление внутри себя. Таким образом, получалось, что контроллер может работать только с теми экземплярами классов, которые он же сам и создал. Это в некотором роде «убивает» гибкость.
Предлагаю избавиться от этого ограничения и вынести создание объектов классов lcl_model и lcl_view за предел контроллера. Но как же тогда контроллер узнает о том, какую модель и какое представление ему использовать? Очень просто - мы их будем передавать во время создания объекта контроллера, прямо в конструктор. И там их будем запоминать в качестве атрибутов класса.
Класс контроллера
* Добавляем контроллеру входные параметры модели и представления
Основная программа
Такой способ создания объектов с их последующей передачей был подсмотрен мной в реализациях MVC на Java.
Возможно, ты заметил еще один плюс от нового способа реализации... Взгляни еще раз на то, как мы стали передавать данные с селекционного экрана! Да-да, нам больше не надо протаскивать их через контроллер, который с ними и так ничего не делал. Теперь мы их передаем напрямую в модель. Причем, если бы у нас были параметры, связанные только с отображением (например, вариант layout'а ALV Grid'а), мы бы их так же передали представлению напрямую. Без посредника в виде контроллера.
Для самостоятельной реализации предлагаю сделать так, чтобы контроллер принимал любую модель и любое представление, у которых бы были методы и атрибуты, используемые в контроллере для взаимодействия компонентов. Подсказка: прочитать подробнее об интерфейсах.
Наш следующий этап использования MVC - это обработка действий пользователя с ALV Grid'ом. Предлагаю рассмотреть его на примере проваливания (drilldown) по номеру единицы оборудования в стандартную транзакцию просмотра IE03.
Вообще, реализаций взаимодействия существует несколько, и у каждой есть свои плюсы и минусы.
Первый вариант - мы можем жестко повесить методы контроллера на события экземпляра ALV Grid'а. Но в таком случае, контроллер будет знать, какой именно объект используется для вывода информации на экран. А также нам придется делать этот объект доступным извне, что не есть хорошо.
Второй вариант - сделать события у представления и уже их обрабатывать в контроллере. Но в такой реализации появляется другая проблема - передача параметров из событий всегда происходит по значению, а не по ссылке. То есть каждый раз будет создаваться новое значение в памяти, а не передаваться ссылка на уже имеющееся значение. Этот вариант мне тоже не очень понравился.
Поэтому я выбрал третий путь - создание интерфейсов для взаимодействия объектов между собой.
Чтобы реализовать третий вариант, объявляем новый интерфейс с единственным методом.
Интерфейс взаимодействия представления с контроллером
Для прочтения полной версии статьи необходимо зайти как зарегистрированный пользователь.
Михаил Короченков (Рейтинг: 98) 15:33, 11 октября 2017
Но прежде чем писать статьи такие наберитесь опыта в данном стиле ибо как пастырь поведете народ к полу-индусскому коду(не похоже что вы в таком стиле создавали действительно крупные Z-ки со множеством экранов, подэкранов и событий).
Вот вам задача на дом: если у вас будет во вью 100-ня событий обрабатываемых, будете 100 методов на каждое событие в интерфейсе создавать?!
Понравилось 1 человеку
Валерий Заузолков (Рейтинг: 143)
Понравилось 1 человеку
Антон Китаев (Рейтинг: 13)
Пока никому не понравилось