que model-view-controller mvp passive-view architectural-patterns

model-view-controller - que es stackexchange



¿Qué alternativas hay para Model-View-Controller? (10)

Al pasar por la universidad y seguir el desarrollo de SO, he oído mucho sobre el patrón de diseño arquitectónico Model-View-Controller. Inadvertidamente utilicé el patrón MVC incluso antes de saber qué era, y todavía lo uso en mi trabajo diario. Por lo que he visto, es probablemente el patrón más popular que se usa hoy en día. De lo que no he escuchado mucho, son los patrones alternativos que puedes usar en lugar de MVC. ¿Qué opciones hay, y por qué razones decidirías usarlas a través de MVC? También me interesa conocer los tipos de sistemas para los que son típicos. Finalmente, ¿cuáles son los pros y contras que vienen con el uso de ellos?

¿Qué pasa con el patrón Observer ? Si no me equivoco, MVC se introdujo en Smalltalk y, posteriormente, varios patrones de publicación / suscripción han entrado en escena.

El patrón de observador (un subconjunto del patrón de publicación / suscripción) es un patrón de diseño de software en el que un objeto, llamado sujeto, mantiene una lista de sus dependientes, llamados observadores, y los notifica automáticamente sobre cualquier cambio de estado, generalmente llamando a uno de sus métodos. Se usa principalmente para implementar sistemas distribuidos de manejo de eventos.

Ej .: El botón Guardar se habilita en una edición, solo cuando hay datos que se guardarán. Otro ejemplo del patrón de observadores es la arquitectura Document View en MFC, donde en la vista se actualiza cuando cambia el documento.

Algunos otros patrones arquitectónicos incluyendo MVC.

Sistemas en capas

TCP / IP

Organización orientada a objetos

Model-View-Controller , Presentation-abstraction-control , Model View Presenter y Model View ViewModel .

Ejemplos serían MVC de ASP.NET, Ruby on Rails y muchos otros.

Evento basado, invocación implícita

Entorno del navegador (DOM)

Arquitectura de tuberías y filtros

Tubos Unix

Repositorios

Intérpretes guiados por tablas

También puede encontrar este artículo de Garlan & Shaw en Arquitectura de Software una buena lectura.

Otro enlace digno de mención sería el artículo sobre patrones arquitectónicos en Wikipedia .

Aunque las respuestas anteriores son bastante correctas, creo que es mucho más importante tener en cuenta que las palabras "patrón de diseño" son completamente desconocidas para el 90% de las personas que crean software. Simplemente comienzan a escribir código.

El desafío no es seleccionar el mejor enfoque de diseño, es convencer a otros de que el diseño tiene valor.

Bueno, está Model-View-Presenter, pero creo que encontrarás que la "alternativa" más común a MVC es realmente la falta de una separación adecuada. Como ejemplo extremo, considere las páginas ASP clásicas donde HTML, VBScript y SQL se encuentran uno al lado del otro en el mismo archivo. (Eso no es un golpe de ASP: encontrarás muchos de esos ejemplos en otros idiomas).

En el marco web Lift utilizamos un enfoque View First . Básicamente, una vista se compone de uno o más fragmentos (algo similar a los controladores) y los fragmentos se pueden anidar. Esto funciona muy bien con las capacidades de procesamiento XML integradas de HTML y Scala.

Ocasionalmente he visto MVC sin la C, donde la vista escucha los cambios en los datos del modelo y altera la representación en consecuencia, y donde los métodos en el modelo están vinculados a los manejadores de eventos para la vista.

Para los proyectos donde la vista es por necesidad estrechamente unida a los datos (como cuando hay componentes visuales que se relacionan directamente con el modelo o atributos del modelo), esto puede ser bastante útil, ya que elimina al "hombre del medio".

Creo que muchos argumentarían, sin embargo, que esto sigue siendo MVC, solo una versión hibridada, y que los enlaces establecidos entre la vista y el modelo son la lógica del controlador.