Saltar al contenido →

Arquitectura de Apps

Al principio de los tiempos, cuando todo se hacía en ensamblador o lenguajes de nivel parecido, los programadores ni se planteaban cosas como los patrones de software, el escalado de las aplicaciones o cosas de eso estilo.

Tuvo que llegar la crisis del software para que la gente del gremio tomara consciencia de que se debía planear el desarrollo de sistemas como si de una obra de aquitectura o ingeniería se tratase.

Necesitábamos planos, saber cómo íbamos a construir las cosas, cómo iban a encajar, cómo iban a comunicarse… y aquí es donde nació la Aquitectura de Aplicaciones.

En este artículo daré un repaso básico a tres de las más conocidas y empleadas hoy en día.

Model View Controller (MVC)

Una de las veteranas que lleva entre nosotros desde principios de los años 70, cuando la programación orientada a objetos estaban en sus inicios y Smalltalk era algo futurista.

Componentes

Modelo. Es la representación de la información que maneja nuestro sistema. Se encarga desde la creación de las entidades hasta del acceso y mantenimiento a las mismas.

Vista. Es el interface con el usuario. Puede ser una vista de una app para iPhone como de los endpoints de un API RESTful.

Controlador. Es el encargado de orquestar la comunicación entre la vista y el modelo. Es quien recoge los eventos de los vista y el que solicita las distintas acciones al modelo.

¿Quién lo usa?

Enciende tu Mac, iPhone o iPad y abre una app de Apple, allí tienes el MVC.

Model View View Model (MVVM)

Diseñada a partir del MVC, nace con la idea de facilitar la separación del desarrollo del interface de usuario del desarrollo de la capa de negocio o del backend.

Fue inventada por Microsoft, concretamente por Ken Cooper y Ted Peters, para facilita el desarrollo de las aplicaciones que empleaban el paradigma de Programación Orientada a Eventos.

Componentes

Model. Es la capa de acceso a datos. Se encarga de gestionar todo lo referente a la información que maneja la App.

View. Igual que la vista en el MVC. Se encarga de pintar en la pantalla la información para el usuario y de disparar los eventos.

View Model. Es una abstracción de la vista que expone métodos y propiedades públicas. Lo más característo es que dispone de un binder que se encarga de comunicar la vista con las propiedades enlazadas en la view model. ¿Y qué es el view model?

El view model es un estado determinado de los datos en el modelo

Binder. Este componente libera al desarrollador de escribir el código que sicroniza la vista con el modelo. Es prescisamente la presencia de este componente la que da sentido a la arquitectura. En el caso de Microsoft es el lenguaje XAML el que hace las veces de Binder.

¿Quién lo usa?

Si has desarrollado con el framework Knockout.JS lo has usado, y las aplicaciones que emplean WPF o Silverlight usan MVVM como la arquitectura recomendada para su desarrollo.

Aviso

Que haya sido desarrollada por Microsoft no quiere decir que no se pueda usar en apps para sistemas Apple, si ves que esta arquitectura cuadra con tu proyecto, úsala.

Hierarchical Model–View–Controller

Presentada en sociedad en la JavaWorld Magazine en el año 2000, esta variante del MVC hace incapie en la reutilización de componentes.

La mayor ventaja que tiene esta arquitectura es que propone una widgetificación de los componentes de tal manera que estos se diseñen para que puendan presentarse en lugares diferentes de la aplicaión o incluso varias veces dentro de la misma vista.

Sin olvidar que nos ayuda a evitar los controladores masivos, esos archivos de código fuente con cerca de 2.000 líneas, o incluso más.

Un ejemplo serían los tuits que se se ven en el vista de actividad de Twitter. Es el mismo componente repetido tantas veces como sea necesario, pero cada componente tiene su propio controlador para gestionar su lógica (Me gusta, Retuit, etc.)

Una de las desventajas puede ser en la gran cantidad de recursos que se pueden llegar a consumi, ya que en lugar de estar centraliado cada componente gestionar las llamadas al modelo.

Componentes

Modelo. Igual que en el MVC. Controla el acceso a los datos de la app.

Vista. Responsable de presentar en pantalla la información requerida por el usuario y de disparar los eventos.

Controlador. Controla y coordina las peticiones que se hacen desde la vista y requiere al modelo los datos necesarios para satisfacerlas.

Se puede establacer una relación padre-hijo entre diferentes controladores, de tal manera que un controlador hijo puede requerir al padre que se haga cargo de una petición en caso de salirse de su área de influencia.

¿Quién lo usa?

A priori podría decir que Twitter o Facebook parece que hacen uso de esta arquitectura.

En las apps para iOS aparece la figura del Container View y sobre todo en las de macOS los NSWindowController pueden estar compuestos por varios NSViewController.

¿Cuál es el mejor aquitectura?

La pregunta que todos nos hemos hecho cuando empezamos en esto, y te respondo con lo que me ha enseñado la experiencia.

Todas son buenas, pero hay que emplearlas cuando sea necesario.

Con esto quiero decir que no hay que usar una arquitectura sólo porque esté de moda o tal proyecto de GitHub la esté usando, si no porque es la más adecuada para nuestra solución.

Haciendo una analogía, si tenemos que construir un rascacielos no lo haremos como se construye una catedral, y para construir una casa de campo unifamiliar no lo haremos como se hace un rascacielos.

Y sobre todo, diseñad un sistema lo más simple posible dentro de su complejidad

No por poner más capas seréis mejores diseñadores, el que es realmente bueno hace simple lo complicado.

Publicado en Arquitectura de Aplicaciones