Frameworks basados en Acciones

Introducción

Como sabemos en programación uno puede modelar un mismo problema de diferentes formas. El paradigma ya establecerá cuales serán nuestras abstracciones más importantes. Por ejemplo, funciones, reglas/predicados, u objetos y mensajes.

Dentro del paradigma de objetos, a su vez, también tomamos decisiones de modelado al definir qué conceptos abstraeremos en clases y objetos.
Así, por ejemplo, cuando identificamos y modelamos la estrategia de orden en un fwk de colecciones como un objeto (ej: Comparator), aplicando un strategy, estamos encontrando y reificando este concepto como una entidad principal e intercambiable (polimórfica). Esto nos dá ciertas ventajas y desventajas.

A la hora de diseñar un framework web, es común a todos que la aplicación constará de:
  • un componente cliente, en el browser, que consta de html + css + javascript
  • un componente en el servidor, con lógica de negocio y de arquitectura (persistencia, transaccionalidad, etc)

Hasta ahí esto se da por el tipo de arquitectura distribuida. Ahora, una característica distintiva del framework será la decisión que tome en cuanto a cómo será la interacción entre el cliente y el servidor. Y cómo será la relación entre los componentes de ambas partes.

Pero más importante es la decisión que toma el framework que establece la metáfora de construcción de aplicaciones. Esto quiere decir, cuánto de su comportamiento mantiene encapsulado, cosa que nosotros programadores de aplicaciones web no tengamos que lidiar con esos problemas. Y por otro lado, qué publica y qué responsabilidades nos deja a nosotros para que implementemos.

Un framework Action-Based parte de la metáfora en que:

  • el componente cliente realiza pedidos independientes de unidades (páginas o segmentos ajax)
  • la responsabilidad del component servidor es responder a esos pedidos.

Esto no es más que la misma arquitectura de HTTP + HTML.

 

Características fundamentales

La responsabilidad principal del servidor, es entonces la de responder a pedidos del cliente. Y estos frameworks no intentar "ocultar" esa responsabilidad o abstraerla complétamente. Es decir que cuando trabajamos sobre uno de estos frameworks, lo que estaremos haciendo es codificando, del lado del servidor, objetos que responderán a pedidos del cliente.

Esto les debería sonar un poco a la arquitectura de Servlets que vimos como base de web. Y corréctamente, ya que se puede pensar como una (pequeña) evolución a esa arquictura. Especialmente al model 2.

Lo que harán estos frameworks es

  • Extender la metáfora request-response al lenguaje del servidor.
  • Dependiendo del framework proveerán en mayor o menor medida utilidades para resolver las problemáticas más comunes:
    • Binding
      • de URL's a código servidor
      • de parámetros a objetos
        • conversión de tipos
        • validaciones
    • Navegación y workflow entre las diferentes páginas
      • configurable
      • dinámica (poder decidir a qué página seguir de acuerdo a una condición)
    • Intentar agilizar el desarrollo
      • Convention over Configuration
    • Internacionalización
    • etc.

Ejemplos de Frameworks Action-Based

En estos últimos años con la superexplosión de frameworks, y en especial en el mundo Java, sugieron varios frameworks web que podríamos categorizar o catalogar como Action-Based (u orientados a acciones).

Los frameworks Action-Based ejemplo que vamos a ver son:

Pero dejamos acá una lista de fwk's similares

  • Tapestry
  • Play framework
  • Struts
  • JSF (aunque algunos lo consideran orientado a componentes)
  • Struts 2
  • etc.


Stateful o Stateless ?

Por lo general este tipo de frameworks no nos impone un modelo stateful ni stateless. Es decir, que se pueden construir ambos tipos de aplicaciones sobre ellos. Sin embargo, suelen estar pensandos para ser utilizados mayormente en aplicaciones stateless.

Esto es, por lo natural de seguir basado en la metáfora request-response, y por la dificultad de mantener estado entre los diferentes request (más allá de la sesión).

Claro que provéen manejo de session, con lo cual uno podría construir una aplicación stateful. Pero por lo general, requiere dedicar esfuerzo por sobre el framework para evitar este manejo manual por toda la aplicación.

Dependiendo de la cálidad y el diseño del framework será factible, y más o menos fácil de extender.


Relación con Component-Based Frameworks

El otro tipo de frameworks web, opuesto a los basados en acciones es el basado en componentes.

La metáfora aquí es:

  • ok, existe la arquitectura distribuída por HTTP y la interacción de cliente/servidor en ella es por request/response, peeeeero...
  • eso no quiere decir que no se pueda abstraer en el lado del servidor, y convertir el diseño del componente server en un diseño en objetos componente en lugar de acciones o handlers de pedidos.

Entonces, la idea es que si bien está el request/response, el fwk nos abstraerá de él. Por ejemplo, en lugar de pensar en que en el server tendremos un servlet o action que atenderá un request, originado porque un usuario seleccionó un opción en el combo de Paises, y que deberemos actualizar otro combo de Provincias. Pensamos en que en el server existe un componente Combo. Nosotros simplemente codificamos el método "onChange" del combo. O aún mejor, si tenemos el concepto de "modelo" detrás del combo, y la idea de binding, quizás no haya que codificar nada. Simplemente declarar la relación entre un combo y el otro. Quizás en el mismo binding

Ej:

new Combo("usuario.pais", "opcionesPaises")

new Combo("usuario.provincia", "usuario.pais.provincias")


Aquí el segundo combo toma las opciones (2do parámetro) como una propiedad collection del objeto valor bindeado por el primer combo.

El ejemplo más claro de framework basado en componentes es Apache Wicket.
Fíjense que en él nunca pensamos en manejar un pedido individual, porque éstos terminan en llamados a métodos de componentes.
Sin embargo la abstracción de "página" y formulario sigue existiendo.


Limitaciones de modelo basado en acciones

Los frameworks basados en acciones suelen limitarnos en cuanto a que:
  • Separan estado de comportamiento:
    • Los ActionBeans/Servlets/Actions serían el comportamiento, compartido entre los diferentes usuarios.
    • La definición de qué es el estado es más dificil, y justamente ese es el problema, porque nos fuerza a pensar en qué scope o contexto y cómo manejar el estado:
      • guardar en session
      • propagar entre responses y futuros requests mediante parámetros hidden.
  • La separación anterior hace dificil la reutilización
    • Ej: en un fwk basado en componentes parece trivial y natural la idea de compartir un panel, en cambio con los actions no tanto.
  • La vista no es un objeto
    • Ok, sí en el lado del cliente, pero para el servidor la vista, es simplemente un template que genera (escupe) html. Una vez que se generó, esa vista se envía al cliente y el server pierde ese estado.
    • En un fwk basado en componentes, las partes de la vista son objetos también (ej: Button en wicket)



Subpáginas (3): Lift Play Framework Stripes
Comments