Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 19
Спасибо, довольно интересно, надо будет попробовать.
У меня давно было ощущение того, что попытка слепой реализации MVC в ABAP только усложняет приложение, без какого либо положительного эффекта.
Попробуйте. Будет интересно услышать обратную связь после применения.
Попытался сделать какой нибудь простенький пример.
Пока вызывает дискомфорт то, что в интерфейсе view жёстко прописана структура контекста.
Пока не понимаю, как можно сделать его более абстрактным.
Хотя, может, я слишком многого хочу от ABAP'а )).
Пока вызывает дискомфорт то, что в интерфейсе view жёстко прописана структура контекста.
Пока не понимаю, как можно сделать его более абстрактным.
Хотя, может, я слишком многого хочу от ABAP'а )).
В чем дискомфорт и зачем ее абстрагировать? Удобно же когда информация для отображения аккумулирована в одном месте.
Я бы предпочёл чтобы был вообще один общий интерфейс для View, а не свой собственный на каждый отдельный отчёт. В таком случае получится реально очень гибкие «кирпичики».
По идее, это можно решить, путём использования ссылок на DATA в классах вместо структур и таблиц. Опять таки, побочный эффект решения — проблемы с читабельностью такой структуры.
По идее, это можно решить, путём использования ссылок на DATA в классах вместо структур и таблиц. Опять таки, побочный эффект решения — проблемы с читабельностью такой структуры.
Уважаемый автор, а зачем нужны все эти дополнительные сущности, по сравнению с базовым вариантом написать напрямую весь код в тексте report в se38?
Вроде никакого повторного использования кода ваш вариант не предполагает..
Для разделения логики приложения от логики пользовательского интерфейса.
Постараюсь высказаться яснее.
Логику приложения отделяют от логики пользовательского интерфейса не просто потому что кто-то сказал, что «это делать хорошо», а для достижения каких-то задач.
Например, это может быть задача упростить дальнейшую поддержку и модернизацию, особенно если этим будет заниматься не тот разработчик, который изначально писал программу.
Я утверждаю, что при таком мотиве гораздо лучше использовать общепринятый подход, т.е. просто выделить в отдельные perform код для выборки данных, вывода ALV и реакции на user-command. Ваша же схема потребует от нового разработчика долго разбираться, какой же там мега-шаблон вы использовали и не дает никаких преимуществ для целей поддержки.
Может быть другая задача — сделать больше одного пользовательского интерфейса для одной и той же функциональности. Например, обычный SAP GIU под Windows и какое-нибудь мобильное приложение. Вот в этом случае усилия по полной изоляции логики интерфейса от логики работы с данными оправданы. Но часто ли у вас встречается такая задача?
Логику приложения отделяют от логики пользовательского интерфейса не просто потому что кто-то сказал, что «это делать хорошо», а для достижения каких-то задач.
Например, это может быть задача упростить дальнейшую поддержку и модернизацию, особенно если этим будет заниматься не тот разработчик, который изначально писал программу.
Я утверждаю, что при таком мотиве гораздо лучше использовать общепринятый подход, т.е. просто выделить в отдельные perform код для выборки данных, вывода ALV и реакции на user-command. Ваша же схема потребует от нового разработчика долго разбираться, какой же там мега-шаблон вы использовали и не дает никаких преимуществ для целей поддержки.
Может быть другая задача — сделать больше одного пользовательского интерфейса для одной и той же функциональности. Например, обычный SAP GIU под Windows и какое-нибудь мобильное приложение. Вот в этом случае усилия по полной изоляции логики интерфейса от логики работы с данными оправданы. Но часто ли у вас встречается такая задача?
Архитектурные паттерны не следует применять во всех задачах подряд. Если у вас простой ALV отчет, то использовать данный подход не имеет смысла. А если есть экраны, подэкраны и дополнительный набор функций, то отсутствие архитектуры может свести к тому, что программа станет не поддерживаемой через некоторое время.
Что касается вашего комментария:
Да, это упростит дальнейшую поддержку и сделает программу более гибкой к расширению функционала
Ваши утверждения не обоснованы. Вызов PERFORM означает использование процедурного программирование. Это не общепринятый подход, а практически единственно возможный способ программирования в ABAP до появления ООП.
Напротив, поддержка будет более простой и гибкой если знать принцип. А для понимания принципа достаточно прикрепить ссылку на статью в задании на разработку ;)
Я в качестве примера приводил когда требуется выводить данные в разных представлениях: ALV, Excel, PDF.
Что касается вашего комментария:
это может быть задача упростить дальнейшую поддержку и модернизацию
Да, это упростит дальнейшую поддержку и сделает программу более гибкой к расширению функционала
Я утверждаю, что при таком мотиве гораздо лучше использовать общепринятый подход, т.е. просто выделить в отдельные perform код для выборки данных, вывода ALV и реакции на user-command
Ваши утверждения не обоснованы. Вызов PERFORM означает использование процедурного программирование. Это не общепринятый подход, а практически единственно возможный способ программирования в ABAP до появления ООП.
Ваша же схема потребует от нового разработчика долго разбираться, какой же там мега-шаблон вы использовали и не дает никаких преимуществ для целей поддержки.
Напротив, поддержка будет более простой и гибкой если знать принцип. А для понимания принципа достаточно прикрепить ссылку на статью в задании на разработку ;)
Может быть другая задача — сделать больше одного пользовательского интерфейса
Я в качестве примера приводил когда требуется выводить данные в разных представлениях: ALV, Excel, PDF.
Думаю, что использование средств ООП в простых отчетах с alv оправданно с точки зрения сокращения времени разработки. Вы можете использовать интерфейсы для определения методов, которые обычно работают в отчете. А для alv-grid можно сделать удобную обертку. А если вы пишете подпрограммы вы неизбежно себя повторяете и тратите кучу времени в рутинных задачах
Согласен в том, что в abap сложно полноценно реализовать mvc, но такой вариант реализации MVA, на мой взгляд, сложен. Хотя иногда приходиться делать что то подобное. Полностью тут я вряд ли опишу свой подход, задам несколько вопросов:
1. Почему бы модель не сделать обработчиком событий view-ера? Так как у события есть sender, модель сможет влиять на view и получать данные о его состоянии.
2. Что плохого в локальных классах, если речь идёт о типовом отчете с селекционным экраном? У меня обычно три класса — application, model, view. Для приложения я использую интерфейс, viewer обычно наследует класс-обертку над cl_gui_alv_grid. Если вариантов представления несколько, есть класс для каждого view.
3. Я раньше тоже в каждом application делал конструктор с параметрами, это слишком долго и плохо поддерживается. Это ещё и мешает прийти к такой архитектуре, которую можно использовать повторно и получать выгоду в скорости
1. Почему бы модель не сделать обработчиком событий view-ера? Так как у события есть sender, модель сможет влиять на view и получать данные о его состоянии.
2. Что плохого в локальных классах, если речь идёт о типовом отчете с селекционным экраном? У меня обычно три класса — application, model, view. Для приложения я использую интерфейс, viewer обычно наследует класс-обертку над cl_gui_alv_grid. Если вариантов представления несколько, есть класс для каждого view.
3. Я раньше тоже в каждом application делал конструктор с параметрами, это слишком долго и плохо поддерживается. Это ещё и мешает прийти к такой архитектуре, которую можно использовать повторно и получать выгоду в скорости
1. Вы предлагаете модели подписываться на события вьювера? Тогда для чего нужен контроллер?
2. Локальные классы имеют доступ к глобальным переменным. Также GUI элементы необходимо будет создавать в основной программе что делает невозможным использовать их в других разработках. Если View наследовать от ALV, то View и Controller будут сильно сопряжены.
3. Если в конструктор передавать структуру с критериями, то такие разработки очень легко поддерживаются. Допустим, расширился экран выбора на несколько параметров. Потребуется расширить структуру CRITERIA и все. Остальная логика не будет затронута.
Данная архитектура проверена временем как на простых отчетах, так и на программах со сложной экранной логикой.
2. Локальные классы имеют доступ к глобальным переменным. Также GUI элементы необходимо будет создавать в основной программе что делает невозможным использовать их в других разработках. Если View наследовать от ALV, то View и Controller будут сильно сопряжены.
3. Если в конструктор передавать структуру с критериями, то такие разработки очень легко поддерживаются. Допустим, расширился экран выбора на несколько параметров. Потребуется расширить структуру CRITERIA и все. Остальная логика не будет затронута.
Данная архитектура проверена временем как на простых отчетах, так и на программах со сложной экранной логикой.
- Есть разные события у того же грида. Одни работают исключительно с данными, влияют на них и их обработку стоит делать в модели, а есть события, которым не нужен доступ к данным, их можно обрабатывать в контроллере. Вообще можно сказать, что cl_gui_alv_grid уже является контроллером.
- Не так страшны глобальные переменные как использование их или их аналогов. В моих отчетах единственные глобальные переменные это параметры селекционного экрана, доступ к которым осуществляется внутри класса application, в других они практически ни к чему.
- В чем ещё плох подход application-а с конструктором? В том что у селекционного экрана куча событий, которые нужно обрабатывать в более менее серьезном отчете. У экранов обычных событий не так много, но все же они есть, и их тоже кто то должен обрабатывать.
Создаётся впечатление, что вы заложник архитектуры и используете ее только ради использования архитектуры.
> В чем ещё плох подход application-а с конструктором? В том что у селекционного экрана куча событий, которые нужно обрабатывать в более менее серьезном отчете. У экранов обычных событий не так много, но все же они есть, и их тоже кто то должен обрабатывать.
Да, у селекционника может быть много событий. А в чем проблема?
Да, у селекционника может быть много событий. А в чем проблема?
Проблемы, может быть и нет. Просто интересно, как вы обрабатываете, например, события INITIALIZATION, AT SELECTION-SCREEN OUTPUT, AT SELECTION-SCREEN, если они будут зависеть от данных, введенных на селекционном экране. По идее, эти события должны обрабатываться классом приложения, но экземпляр этого класса вы создаете только в START-OF-SELECTION.
Эти события реализую непосредственно в коде основной программы. В Application передаю уже выбранные параметры.
Т.е. получается, что:
1. класс Application не полностью реализует функционал приложения, что, на мой взгляд, странно. Интересно, как вы будете строить архитектуру решения, если вам потребуется сделать alv grid на селекционном экране для выбора, например классов классификации, а в отчете будет еще два alv grid-а;
2. скорее всего, ни один такой отчет вы не используете дважды и каждый раз пишете много одинакового или однотипного кода, т.е. во времени разработки нет выигрыша;
1. класс Application не полностью реализует функционал приложения, что, на мой взгляд, странно. Интересно, как вы будете строить архитектуру решения, если вам потребуется сделать alv grid на селекционном экране для выбора, например классов классификации, а в отчете будет еще два alv grid-а;
2. скорее всего, ни один такой отчет вы не используете дважды и каждый раз пишете много одинакового или однотипного кода, т.е. во времени разработки нет выигрыша;
По идее, эту проблему можно решить, создавая APPLICATION в LOAD-OF-PROGRAM.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Реализация MVVM в ABAP