El patrón Model-View-Controller ha existido desde hace muchisismo años. Incluso, las aplicaciones Web que se desarrollan en Java lo implementan por defecto desde hace más de 10 años. Sin embargo, en el stack de tecnologías de Microsoft su uso se viene masificando desde la introducción del mismo con ASP.NET. Esto es una gran noticia porque nos permite aplicarle un patrón a la capa de presentación. En este post sin embargo no me voy a enfocar en las ventajas que podríamos obtener utilizando el MVC si no más bien los problemas que tendríamos si usamos el MVC de manera incorrecta.
El MVC me permite separar la lógica del negocio – dominio – de la forma en que se va a presentar al usuario la información. Esto nos da muchisimas ventajas puesto que puedo variar no solo la forma en que se presentan las pantallas, si no que también no dependo estrictamente de la tecnología que este utilizando en el UI. Algunas otras ventajas se pueden encontrar aquí. Este es el esquema generalizado del patrón MVC.
Sin embargo, cuando pensamos en aplicaciones del tipo “enterprise” tenemos que tener encuenta algunas cosas que siempre nos harán la vida más sencilla a la hora de diseñar y extender nuestras aplicaciones. Por ejemplo, nuestra lógica de negocios no siempre va ser accedida por interfaces de usuario creadas por nosotros mismos, ya que en el mundo interconectado en que vivimos es probable que nuestras organizaciones se comuniquen e integren con otras organizaciones para expander sus posibilidades de negocio, y estos partners no van a querer poner nuestro UI en las máquinas de sus agentes, sino que van a desear consumir nuestro negocios desde sus sistemas. Esto implica que debería existir un servicio – o varios – que le permitan al partner integrar sus sistemas con los nuestros. En este contexto lo ideal es que la lógica de negocios se reutilice a través de una capa de servicios tal y como se muestra en esta imágen tomada de pattern and practices y que reutilicé en un post anterior.
.png)
Esto le va a permitir al negocios ventajas tales como:
- La empresa se asegura que todos los consumidores de la lógica de negocio, utiliza los mismos procesos o flujos, con lo cual podemos tener un proceso estandarizado para todos los usuarios del mismo.
- Existe verdaderamente reutilización, lo que nos permite ahorrar en el costo de la implementación.
- Cuando hay un cambio en la lógica del negocio, solo hay que llevar a cabo ese cambio en un solo lugar.
- Aplico esquemas de autenticación y autorización de forma uniforme en el mismo sitio.
- La integración con otras aplicaciones es más simple.
- Interactuar con la nube es más sencillo – es decir llevar aplicaciones desde nuestro datacenters a Windows Azure por ejemplo.
En este contexto, cual sería el esquema de arquitectura que deberíamos utilizar? A continuación se presenta una esquema genérico en donde obtenemos las ventajas mencionadas anteriormente.
¿Y que tiene que ver esto con el MVC? Pues bien, el MVC es un patrón para la capa de UI. Esto permite como dije anteriormente crear interfaces más versátiles y más fáciles de cambiar. Sin embargo, si la interacción con la lógica de negocios no esta bien separada, vamos a terminar utilizando el controller como lógica de negocios, y en este caso vamos a quedar con toda la funcionalidad encapsulada y lista para ser utilizada exclusivamente en nuestra aplicación. Esto no esta mal si la aplicación es una unidad de negocio que no interactúa ni expone funcionalidad a otras unidades – aplicaciones – en el contexto de la empresa, lo cual es dificil de encontrar. Además, vamos a disminuir la posibilidad de reutilización ya que la funcionalidad va a queda en el sitio Web – es cierto que existen formas de accederla desde otras aplicaciones pero eso no es la idea, sino más bien lo que se busca es que este disponible directamente desde nuestros servidor de aplicaciones. En lo que respecta a mantenimiento, cualquier cambio que requiera la empresa en su funcionamiento, va a tener que ser hecho en todas las aplicaciones que de alguna forma u otra tienen que ver con el procedimiento, y siendo asi el MVC también debería tener e cambio.
Por lo tanto, el MVC en nuestra esquema anterior de arquitectura debería lucir como se ve en la siguiente figura.
No hay comentarios:
Publicar un comentario