Inturiasgary’s Blog

marzo 4, 2010

Frameworks Web de desarrollo

Filed under: Uncategorized — inturiasgary @ 12:49 pm

Existen varios tipos de frameworks Web: los orientados a interfaz de usuario, como Java Server Faces, orientados a aplicaciones de publicación de documentos, como Coocon, orientados a la parte de control de eventos, como Struts y algunos que incluyen varios elementos como Tapestry.

La mayoría de los frameworks Web se encargan de ofrecer una capa de controladores de acuerdo con el patrón MVC o con el modelo 2 de servlets y JSP, ofreciendo mecanismos para facilitar la integración con otras herramientas para la implementación de las capas de negocio y presentación.

Características:

A continuación se enuncian una serie de características que podemos encontrar en prácticamente todos los frameworks existentes.

  • Abstracción de URLs y sesiones: No es necesario manipular directamente las URLs ni las sesiones, el framework ya se encarga de hacerlo.
  • Acceso a datos: Incluyen las herramientas e interfaces necesarias para integrarse con herramientas de acceso a datos, en BBDD, XML, etc.
  • Controladores: La mayoría de los frameworks implementa una serie de controladores para gestionar eventos, como una introducción de datos mediante un formulario o el acceso a una pagina Web. Estos controladores suelen ser fácilmente adaptables a las necesidades de un proyecto concreto.
  • Autenticación y control de acceso: Incluyen mecanismos para la identificación de usuarios mediante login y password, permiten restringir acceso a los usuarios a determinadas paginas.
  • Internacionalización
  • Separación entre diseño y contenido

Arquitectura MVC

Filed under: Uncategorized — inturiasgary @ 12:40 pm

Debido a que la mayoría de los frameworks conocidos adoptan por esta arquitectura o caso contrario similar. Tenemos que contemplar estos aspectos básicos.

Conceptos básicos:

  • Modelo, es el responsable de:
  • Acceder a la capa de almacenamiento de datos. Lo ideal es que el modelos sea independiente del sistema de almacenamiento.
  • Define las reglas de negocio(la funcionalidad del sistema)
  • Lleva un registro de las vistas y controladores del sistema.
  • Si estamos ante un modelo activo, notificara a las vistas los cambios que en los datos pueda producir un agente externo.
  • Vista, es el responsable de:
  • Recibir datos del modelo y los muestra al usuario.
  • Tienen un registro de su controlador asociado.
  • Pueden dar el servicio de actualizacion, para que sea invocado por el controlador o por el modelo cuando es un modelo activo.
  • Controlador, es el responsable de:
  • Recibir los elementos de entrada.
  • Contiene reglas de gestión de eventos, estas acciones pueden suponer peticiones al modelo o a las vistas.

Aunque se puedan encontrar diferentes implementaciones de MVC, el flujo que sigue el control generalmente es el siguiente:

  • El usuario interactúa con la interfaz de usuario de alguna forma(como ser: pulsar un botón, enlace, etc.)
  • El controlador recibe(por parte de los objetos de la interfaz-vista) la notificación de la acción solicitada por el usuario. El controlador gestiona el evento que llega, frecuentemente a través de un gestor de eventos(handler) o callback.
  • El controlador accede al modelo, actualizándolo, posiblemente modificándolo de forma adecuada a la acción solicitada por el usuario(por ejemplo, el controlador actualiza el carro de compra del usuario). Los controladores complejos están a menudo estructurados usando un patrón de comando que encapsula las acciones y simplifica su extensión.
  • El controlador delega a los objetos de la vista la tarea de desplegar la interfaz de usuario. La vista obtiene sus datos del modelo para generar la interfaz apropiada para el usuario donde se refleja los cambios en el modelo(por ejemplo, produce un listado del contenido del carro de compra). El modelo no debe tener conocimiento directo sobre la vista. Sin embargo, el patrón de observador puede ser utilizado para proveer cierta indirección entre el modelo y la vista, permitiendo al modelo notificar a los interesados de cualquier cambio. Un objeto vista puede registrarse con el modelo y esperar los cambios, pero aun así el modelo en si mismo sigue sin saber nada de la vista. El controlador no pasa objetos de dominio(el modelo) a la vista aunque puede dar orden a la vista para que se actualice, En algunas implementaciones la vista no tiene acceso directo al modelo, dejando que el controlador envíe los datos del modelo a la vista.
  • La interfaz de usuario espera nuevas interacciones del usuario, comenzando el ciclo nuevamente.

Blog de WordPress.com.