Patrones MVC y MVVM
No describiré en detalle cómo funcionan los patrones MVC y MVVM en este artículo. Daré solo los puntos principales que necesitaremos en el futuro.
La principal diferencia entre MVC y MVVM es que en el primer Controller conoce tanto la Vista como el Modelo, también se permite que la Vista conozca sobre el Modelo.
En el patrón MVVM, la relación entre capas es más débil. View solo conoce ViewModel y ViewModel only Model. View recibe datos de ViewModel a través de la referencia DataContex.
El patrón MVVM está diseñado para el desarrollo de WPF en C #. Pero su idea también se puede aplicar a ABAP.
Problemas de MVC en ABAP
Al implementar MVC, por regla general, las clases de modelo se incorporan a la definición global y las clases de vista y controlador a la local. El uso de clases locales se debe a la necesidad de interactuar con los elementos de la GUI. El hecho es que no puede construir una GUI completa en clases ABAP. En las clases de Vista, puede usar la funcionalidad para formar la GUI (CL_SALV_TABLE, REUSE_ALV_GRID_DISPLAY, etc.), pero esto no es suficiente. Es imposible crear estados de GUI, encabezados, pantallas, PBO, PAI en el aula.
La vista local y el controlador tienen varias desventajas:
- View y Controller tienen acceso a todas las variables y parámetros globales de la pantalla de selección.
- PBO PAI Controller View ( ALV) View ( ALV). View, Controller, View Controller. , .. , Low Coupling.
MVVM ABAP MVA
Queriendo aprovechar MVVM en ABAP y hacer que las capas sean más independientes, definí el siguiente patrón de desarrollo para mí.
Dado que es imposible implementar MVVM en su forma pura en ABAP, no es del todo correcto usar ViewModel. Entonces, en lugar de ViewModel y Controller, uso Application.
El principio de separación lógica es similar al principio MVVM. La vista pasa los comandos del usuario a la aplicación y la aplicación actúa sobre el modelo. No hay comentarios.
Una característica de las aplicaciones ABAP es que la vista solo se puede actualizar después de la acción del usuario. Incluso si algún proceso asincrónico cambia el modelo, no podrá iniciar la actualización de la vista. Esta característica le permite debilitar la relación modelo-vista y delegar la función de actualizar la vista a la vista misma. En otras palabras, la idea misma debe decidir cuándo renovarse y cuándo no.
Concepto MVA
La implementación de MVA se basa en un enfoque orientado a objetos, donde se implementarán una o más clases para cada capa de la arquitectura. Cada una de las capas tiene varias propiedades.
Ver (Ver y IView):
- MVA trabaja con la abstracción de vista IView. Todas las clases de View deben contener una implementación de IView.
- IView contiene eventos que requieren interacción con el modelo
- IView contiene contexto: un enlace a los datos del modelo que debe mostrarse al usuario
- La vista puede contener lógica empresarial que no requiera interacción con el modelo. Por ejemplo, si desea implementar desde ALV una caída en la tarjeta de contraparte, esta lógica se aplicará a la vista.
- View contiene elementos de la GUI en un grupo de funciones que está asociado con la clase View.
Solicitud:
- Sirve como enlace de la vista y el modelo y es el punto de entrada a la aplicación.
- Tiene criterios de lanzamiento: un conjunto de parámetros que determinan con qué parámetros se debe iniciar la aplicación. Suelen ser los parámetros de la pantalla de selección.
- Los criterios de aplicación consisten en modelos y criterios de presentación. Por ejemplo, si la pantalla de selección requiere que ingrese una fecha de publicación y especifique una marca de salida de informe PDF o ALV, entonces la fecha de publicación se referirá a los criterios del modelo y la marca PDF y ALV a los criterios de presentación.
- Los criterios de lanzamiento se pasan al diseñador de la aplicación. La aplicación crea un modelo y una vista, se suscribe a eventos de vista y vincula el contexto de la vista al modelo.
Modelo:
- Contiene los atributos públicos que necesita la vista.
- Contiene los criterios para calcular el modelo y el método de inicialización.
Implementación de MVA
Consideremos la implementación de MVA usando el ejemplo de un informe de flujo de materiales. El botón de actualización de datos se utilizará como interacción con el modelo.
El diagrama de clases se verá así.
Modelo. El diseñador del modelo tomará los criterios de selección de datos como entrada. La clase tendrá métodos para inicializar y actualizar datos, así como un atributo con datos para mostrar.
Yo veo. La interfaz de vista contiene métodos para establecer un contexto, mostrar una vista, eventos y definir tipos de contexto.
IView contiene una descripción de la estructura del contexto y los campos de la estructura deben ser View de referencia
.La vista implementa la interfaz IView. Además, todos los eventos de usuario son registrados por la clase View y solo generan aquellos eventos que necesitan ser procesados por la aplicación. En los parámetros del evento, debe pasar todos los datos necesarios de la Vista (por ejemplo, las líneas ALV resaltadas).
Implementación de la clase View en la vista ALV
En esta implementación necesitamos definir el estado de la GUI, para esto crearemos una FM y la conectaremos a la instancia CL_SALV_TABLE
Es importante que todos los eventos UI sean recibidos por la Vista (en este caso, vía ON_USER_COMMAND) y, si es necesario, la Vista hace RAISE EVENT para la Aplicación. Este enfoque hace que la Vista y la Aplicación sean más independientes.
Solicitud.El diseñador de la aplicación toma los criterios de la aplicación (opciones de pantalla de selección) como entrada y crea una instancia del modelo y la vista, se suscribe a los eventos de la vista y vincula el contexto de la vista al modelo. El constructor es el único lugar donde la aplicación conoce la vista. La aplicación contiene un método RUN que inicia el programa. El inicio de una aplicación se puede comparar con el inicio de una transacción con parámetros de pantalla predefinidos. Esto permite que se utilice desde otros programas sin ENVIAR.
Aplicación de lanzamiento. Ahora estamos haciendo un programa que lanzará la aplicación.
Eso es todo, la aplicación está lista. Puedes ver el resultado.
Lógica empresarial en el lado de la vista. Los eventos que no requieren llamar al modelo y al controlador se pueden manejar en la propia Vista.
Por ejemplo, si desea implementar la apertura de MM03 haciendo doble clic en MATNR, entonces el procesamiento de esta lógica se puede hacer en el lado Vista.
Esta lógica se traslada al nivel de Vista basándose en consideraciones: no es necesario abordar el modelo para obtener datos adicionales; la lógica solo se aplica a ALV, es decir si hubo una implementación de Ver en forma de Excel o PDF, entonces este evento no podría procesarse.
Referencias
Patrones de diseño en objetos ABAP
Patrones para principiantes: MVC vs MVP vs MVVM
Patrones arquitectónicos en ABAP: MVC, MVP, MVVM, MVA