MVC y Arquitectura de N-capas

¿Qué es una arquitectura en capas?

En ingeniería del software, una arquitectura en capas se enfoca en la agrupación de funcionalidades relacionadas de una aplicación, en diferentes capas que son apiladas verticalmente. Las funcionalidades de cada capa corresponden a un rol o responsabilidad concreta. La comunicación entre capas es explícita y las capas están débilmente acopladas, es decir, pueden operar de forma independiente o con poca dependencia entre ellas. Dividir la aplicación en capas separadas con diferentes roles y funcionalidades nos ayuda a maximizar la mantenibilidad del código, optimizar la forma en como la aplicación funciona a la hora de implementarla de diferentes maneras y provee una delimitación clara entre las ubicaciones donde poder tomar decisiones de diseño o alguna tecnología concreta.

Las capas de la aplicación pueden residir en la misma máquina física o pueden estar distribuidas en diferentes máquinas y los componentes de cada capa se comunican con componentes de otras capas a través de interfaces bien definidas.

La arquitectura más común es una arquitectura en 3 capas:

  • Capa de presentación (presentation layer). Esta capa contiene las funcionalidades de usuario responsables de manejar la interacción del usuario con el sistema.
  • Capa de negocio (business layer). Esta capa implementa la funcionalidad del núcleo del sistema, y encapsula la lógica de negocio relevante.
  • Capa de datos (data layer). Esta capa proporciona acceso a fuentes de datos de la aplicación.

¿Qué es el patrón MVC?

Es uno de los patrones más usados para estructurar la interfaz de usuario, lo que quiere decir que este patrón se implementa dentro de la capa de presentación. La idea principal tras este patrón es hacer una clara división entre los objetos del dominio que modelan la percepción del mundo real, y los objetos de presentación, que son los elementos de la interfaz de usuario que vemos en la pantalla. Los objetos de dominio tienen que ser completamente autónomos y funcionar sin depender de los componentes de presentación.

Tanto la vista como el controlador dependen (conocen) el modelo, pero el modelo no depende de ninguno de ellos.

  • Modelo. Controla el comportamiento de los datos de la aplicación; responde a las peticiones de información sobre su estado (normalmente provenientes de la vista) y responde a las instrucciones de cambio de estado (normalmente provenientes del controlador).
  • Vista. Maneja la información de la pantalla.
  • Controlador. Interpreta la entrada de teclado y ratón, e informa al modelo y/o a la vista para realizar la acción apropiada.

Principal error que se suele cometer

Desde mi punto de vista, uno de los errores más comunes que se suele cometer cuando estamos empezando en el diseño de componentes software, es el de intentar visualizar el patrón MVC como una arquitectura independiente equiparable a la arquitectura de n-capas. Por ejemplo, se tiende a decir que el modelo corresponde con la capa de negocio y datos en una arquitectura en capas, la vista con la capa de presentación y que el controlador se asocia con la capa de presentación y la capa de negocio, cuando la realidad es que el patrón MVC son componentes de la capa de presentación.


Cabe destacar que el modelo sería un componente de alto nivel que haría uso de funcionalidades expuestas por la capa de negocio.

Bibliografía

Libros y webs con muy buen contenido de donde he sacado gran parte de la información:

Gracias por leer el artículo, espero tus comentarios.

MVC Arquitectura de N-capas Arquitectura de 3 capas Ingenieria de software