Implementando MVVM em ABAP

Após a formatura, trabalhei como programador C # por vários anos. Tenho desenvolvido aplicativos WPF usando o padrão de design MVVM. Então mudei para ABAP. Para minha surpresa, descobri que ABAP é mais uma linguagem procedural do que uma linguagem orientada a objetos, embora a SAP esteja trabalhando duro para avançar o paradigma OO. O padrão de arquitetura MVC é geralmente usado para separar a lógica de negócios da GUI. Cada vez que tentei implementar o padrão MVC, enfrentei certas dificuldades que tornam o programa ainda mais difícil de manter do que se estivesse escrito em procedimentos. Apesar de a implementação do MVC ser descrita em detalhes e com exemplos no livro Design Patterns in ABAP Objects e em recursos especializados ( sapland.ru , blogs.sap.come outros), os problemas com a separação da lógica permanecem. Na implementação do MVC em ABAP, o Modelo permanece uma parte independente, e a Visualização e o Controlador estão intimamente relacionados. O forte acoplamento entre View e Controller torna difícil manter e dimensionar. O que se segue descreve por que isso acontece e o que fazer a respeito.

Padrões MVC e MVVM

Não vou descrever em detalhes como os padrões MVC e MVVM funcionam neste artigo. Darei apenas os pontos principais de que precisaremos no futuro.



A principal diferença entre MVC e MVVM é que no primeiro Controller conhece tanto a View quanto o Model, também é permitido que a View conheça o Model.







No padrão MVVM, o relacionamento entre as camadas é mais fraco. View apenas conhece ViewModel e ViewModel apenas Model. View recebe dados de ViewModel por meio de referência DataContex.







O padrão MVVM é projetado para desenvolvimento WPF em C #. Mas sua ideia pode ser aplicada ao ABAP também.

Problemas MVC em ABAP

Ao implementar MVC, como regra, as classes Model são trazidas para a definição global e as classes View e Controller para a local. O uso de classes locais se deve à necessidade de interagir com os elementos da GUI. O ponto é que é impossível construir uma GUI completa em classes ABAP. Nas classes View, você pode usar a funcionalidade para formar a GUI (CL_SALV_TABLE, REUSE_ALV_GRID_DISPLAY, etc.), mas isso não é suficiente. É impossível criar status de GUI, cabeçalhos, telas, PBO, PAI na sala de aula.



A visualização local e o controlador têm várias desvantagens:

1. View e Controller têm acesso a todas as variáveis ​​globais e parâmetros da tela de seleção.
2. PBO PAI Controller View ( ALV) View ( ALV). View, Controller, View Controller. , .. , Low Coupling.

MVVM ABAP MVA

Querendo aproveitar as vantagens do MVVM no ABAP e tornar as camadas mais independentes, defini o seguinte padrão de desenvolvimento para mim.







Visto que é impossível implementar o MVVM em sua forma pura no ABAP, não é totalmente correto usar o ViewModel. Portanto, em vez de ViewModel e Controller, eu uso o Application.



O princípio de separação lógica é semelhante ao princípio MVVM. A visualização passa os comandos do usuário para o aplicativo e o aplicativo atua no modelo. Não há feedback.

Um recurso dos aplicativos ABAP é que a visualização só pode ser atualizada após a ação do usuário. Mesmo se algum processo assíncrono alterar o modelo, ele não será capaz de iniciar a atualização da visualização. Este recurso permite enfraquecer o relacionamento modelo-visualização e delegar a função de atualizar a visualização para a própria visualização. Em outras palavras, a própria ideia deve decidir quando se renovar e quando não.

Conceito MVA

A implementação do MVA é baseada em uma abordagem orientada a objetos, onde uma ou mais classes serão implementadas para cada camada da arquitetura. Cada uma das camadas possui várias propriedades.



Ver (ver e ver):

• O MVA trabalha com a abstração da visão IView. Todas as classes de exibição devem conter uma implementação IView.
• IView contém eventos que requerem interação com o modelo
• IView contém um contexto - um link para os dados do modelo que precisam ser exibidos para o usuário
• A Visualização pode conter lógica de negócios que não requer interação com o modelo. Por exemplo, se você deseja implementar de ALV uma queda no cartão da contraparte, esta lógica será aplicada à visualização.
• View contém elementos da GUI em um grupo de funções associadas à classe View.

Inscrição:

• Atua como uma ligação da vista e do modelo e é o ponto de entrada para o aplicativo.
• Possui critérios de inicialização - um conjunto de parâmetros que determinam com quais parâmetros o aplicativo deve ser iniciado. Normalmente, são os parâmetros da tela de seleção.
• Os critérios de aplicação consistem em critérios de modelo e apresentação. Por exemplo, se a tela de seleção exigir que você insira uma data de lançamento e especifique um indicador de saída de relatório PDF ou ALV, a data de lançamento fará referência aos critérios do modelo e o indicador PDF e ALV aos critérios de apresentação.
• Os critérios de inicialização são passados ​​para o designer do aplicativo. O aplicativo cria um modelo e uma visualização, se inscreve para visualizar eventos e vincula o contexto da visualização ao modelo.

Modelo:

• Contém os atributos públicos de que a visualização precisa.
• Contém os critérios de cálculo do modelo e o método de inicialização.

Implementação MVA

Vamos considerar a implementação do MVA usando o exemplo de um relatório de fluxo de material. O botão de atualização de dados será usado como interação com o modelo.



O diagrama de classes será semelhante a este.







Modelo. O designer do modelo tomará os critérios de seleção de dados como entrada. A classe terá métodos para inicializar e atualizar dados, bem como um atributo com dados a serem exibidos.















Eu vejo. A interface de visualização contém métodos para definir um contexto, exibir uma visualização, eventos e definir tipos de contexto.















IView contém uma descrição da estrutura do contexto, e os campos da estrutura devem ser a visão de referência







.A visualização implementa a interface IView. Além disso, todos os eventos do usuário são registrados pela classe View e apenas geram aqueles eventos que precisam ser processados ​​pelo aplicativo. Nos parâmetros do evento, deve-se passar todos os dados necessários da Visualização (por exemplo, as linhas ALV destacadas).



Implementação da classe View na view ALV







Nesta implementação, precisamos definir o status da GUI, para isso iremos criar um FM e conectá-lo à instância CL_SALV_TABLE.







É importante que todos os eventos de UI sejam recebidos pela View (neste caso, via ON_USER_COMMAND) e, se necessário, a View faz RAISE EVENT para a Aplicação. Essa abordagem torna a Visualização e o Aplicativo mais independentes.



Inscrição.O designer do aplicativo pega os critérios do aplicativo (opções de tela de seleção) como entrada e instancia o Modelo e a Visualização, inscreve-se nos eventos da Visualização e associa o contexto da Visualização ao Modelo. O construtor é o único lugar onde o aplicativo conhece a View. O aplicativo contém um método RUN que inicia o programa. Iniciar um aplicativo pode ser comparado a iniciar uma transação com parâmetros de tela predefinidos. Isso permite que ele seja usado a partir de outros programas sem SUBMIT.







Iniciando o aplicativo. Agora estamos fazendo um programa que iniciará o aplicativo.







É isso, o aplicativo está pronto. Você pode assistir o resultado.







Lógica de negócios no lado da Visualização. Os eventos que não requerem a chamada do modelo e do controlador podem ser tratados na própria Visualização.



Por exemplo, se você deseja implementar a abertura de MM03 clicando duas vezes em MATNR, o processamento dessa lógica pode ser feito no lado da Visualização.







Essa lógica é movida para o nível de Visualização com base em considerações: o modelo não precisa ser endereçado para dados adicionais; a lógica só se aplica a ALV, ou seja, se houvesse implementação do View em formato Excel ou PDF, então este evento não poderia ser processado.



Referências



Padrões de projeto em padrões de objetos ABAP

para iniciantes: MVC vs MVP vs MVVM

Padrões arquitetônicos em ABAP: MVC, MVP, MVVM, MVA