Para ponernos en contexto, un muy breve resumen de ambos: en MVC, tenemos un modelo que define una entidad, y la vista y controlador observan esta entidad para: (1) en el caso de la vista, mostrarla al usuario y permitir que el usuario realice acciones sobre ella y (2) en el caso del controlador, definir la lógica de negocio y responder a las acciones del usuario en la vista actual sobre el modelo. Dependiendo de una acción sobre un modelo, el controlador se encarga también de señalar la vista que se debe mostrar seguidamente.
En el caso de MVP, existe menos acople entre el modelo, la vista y el presentador. De esta forma, la vista se encarga exclusivamente de mostrar información al usuario y cualquier acción la delega al presentador que se encarga de comunicarse con el modelo.
Conceptualmente a veces se confunde entre MVC y MVP. A veces, incluso, se habla de MVC aunque realmente se refiere a MVP. Si queréis más información sobre patrones de diseño en interfaz de usuario, quién mejor que el maestro Martin Fowler en este enlace.
Componentes dirigidos por datos
Por un lado, tenemos datos en lugar de modelo y que se traen mediante entidades llamada fuente de datos, que se encargan de realizar la petición y procesar la respuesta de, por ejemplo, un servidor de servicios REST. Por otro lado, tenemos componentes que se sitúan en una vista, se enlazan con una fuente de datos y muestran los datos al usuario.
Con esta breve introducción, podríamos pensar que este diseño es un derivado del MVP, dónde la fuente de datos haría de presentador y la vista sería un conjunto de componentes. El modelo vendría a ser los datos que se comunican entre ellos. Sin embargo, existen una serie de detalles que marcan la diferencia:
- Un presentador no es una simple fuente de datos. Se encarga también de implementar la lógica de negocio que interacciona con las acciones de los usuarios.
- Una vista no es solo una composición de componentes. Dependiendo de la vista, se querrá representar información siguiendo algún propósito. De esta forma, si quitamos la vista de la ecuación, quizás sería mas correcto mirar a un componente como una pequeña vista reusable, por lo que el término componente quizás no sea el más idóneo.
- Si enlazamos directamente un componente multipropósito y reusable con una fuente de datos, estamos añadiendo complejidad (lógica para adaptar los datos al componente, petición y llamada a la fuente de datos para realizar alguna acción, etc...) a un componente que debería de ser lo más simple posible para ser lo más reusable posible y tener un mejor mantenimiento.
- Como último punto y, considero, que más importante: si trasladamos la funcionalidad a componentes para mostrar una única vista, probablemente tengamos problemas de sincronización ya que distintos componentes posiblemente pidan la misma información. Por supuesto, podemos solucionar estos problemas añadiendo mecanismos de exclusión y caché, pero ¿es necesario?.
Posiblemente, me he dejado otras puntos importantes, pero las de arriba me parecen más que suficientes para señalar que este patrón de diseño tiene una serie de desventajas que pueden llevar a convertirlo en un anti-patrón ya que no existe un marcado desacople de funcionalidad y hacerlo fácilmente testable y mantenible puede ser una tarea bastante compleja. Como todo patrón de diseño, seguro que tiene ciertos escenarios en los que se recomiende su aplicación, sin embargo, desde aquí, se recomienda que, como en todos los casos, se analice bien las ventajas y desventajas.
No hay comentarios:
Publicar un comentario