model view controller - pattern - ¿Qué es MVC y cuáles son sus ventajas?

mvc en python (11)

Encontré Qué son mvp y mvc y cuál es la diferencia, pero en realidad no respondió esta pregunta.

Recientemente comencé a usar MVC porque es parte del marco que yo y mi compañero de trabajo vamos a utilizar. Lo elegimos porque parecía sencillo y el proceso separado de la pantalla, ¿hay otras ventajas además de las que no conocemos y que podríamos estar perdiendo?

Pros

La pantalla y el procesamiento están separados

Contras

Ninguno hasta el momento

! [arquitectura mvc] [1]

Model-view-controller (MVC) es un patrón arquitectónico de software para implementar interfaces de usuario. Divide una aplicación de software dada en tres partes interconectadas, a fin de separar las representaciones internas de información de las formas en que se presenta o acepta la información del usuario.

Creo que otro beneficio del uso del patrón MVC es que abre las puertas a otros enfoques del diseño, como MVP / Presenter primero y muchos otros patrones de MV *.

Sin esta segregación fundamental de los "componentes" del diseño, la adopción de estas técnicas sería mucho más difícil.

Creo que ayuda a que su código esté aún más basado en la interfaz. No solo dentro del proyecto individual, sino que casi puede comenzar a desarrollar "vistas" comunes, lo que significa que puede moldear mucho más del código "gruñido" utilizado en sus aplicaciones . Por ejemplo, una "vista de datos" muy abstracta que simplemente toma un montón de datos y los arroja a un diseño de cuadrícula común.

Editar:

Si mal no recuerdo, este es un buen podcast en patrones MV * (¡lo escuché hace un tiempo!)

Jeff tiene una publicación al respecto, de lo contrario, encontré algunos documentos útiles en el sitio web de Apple, en los tutoriales de Cocoa ( este, por ejemplo).

La principal ventaja de la arquitectura MVC es diferenciar las capas de un proyecto en Model, View y Controller para la reutilización del código, mantenimiento y código fáciles de mantener. Lo mejor es que el desarrollador se siente bien al agregar un código entre el mantenimiento del proyecto.

Aquí puede ver algunos puntos más sobre las principales ventajas de la arquitectura MVC .

La separación de las preocupaciones es el biggy.

Ser capaz de separar estos componentes hace que el código sea más fácil de reutilizar y probar de forma independiente. Si no sabe realmente qué es MVC, tenga cuidado de tratar de comprender las opiniones de las personas, ya que todavía hay algo de controversia sobre lo que es el "Modelo" (si se trata de objetos comerciales / DataSets / DataTables o si representa el servicio subyacente). capa).

He visto todo tipo de implementaciones que se autodenominan MVC, pero no exactamente, y como los comentarios en el artículo de Jeff muestran que MVC es un punto polémico en el que no creo que los desarrolladores lleguen a estar de acuerdo.

here una buena recopilación de todos los diferentes tipos de MVC.

MVC es la separación del modelo, la vista y el controlador: nada más, nada menos. Es simplemente un paradigma; un ideal que debe tener en mente cuando diseña clases. Evite mezclar código de las tres categorías en una clase.

Por ejemplo, aunque una vista de cuadrícula de tabla obviamente debería presentar datos una vez mostrados, no debería tener un código sobre dónde recuperar los datos o cómo es su estructura nativa (el modelo ). Del mismo modo, si bien puede tener una función para resumir una columna, se supone que la suma real tiene lugar en el controlador .

Un cuadro de diálogo ''guardar archivo'' ( vista ) finalmente pasa la ruta, una vez elegido por el usuario, al controlador , que luego le pregunta al modelo por los datos, y hace el ahorro real.

Esta separación de responsabilidades permite flexibilidad en el futuro. Por ejemplo, dado que a la vista no le importa el modelo subyacente, es más fácil admitir múltiples formatos de archivo: simplemente agregue una subclase modelo para cada uno.

Separa el Modelo y la Vista controlados por un Controlador. En lo que respecta al Modelo, Sus Modelos deben seguir la arquitectura OO, las mejoras futuras y demás mantenimiento de la base de códigos deben ser muy fáciles y la base del código debe ser reutilizable.

El mismo modelo puede tener cualquier número de vistas, por ejemplo) la misma información se puede mostrar en diferentes vistas gráficas. La misma vista puede tener diferentes no. De modelos, por ejemplo) diferentes detalles se pueden mostrar como un solo gráfico decir como un gráfico de barras. Esto es lo que es la reutilización de View y Model.

Mejoras en las vistas y otro soporte de nuevas tecnologías para construir la vista se pueden implementar fácilmente.

El tipo que está trabajando en la vista de dosis no necesita conocer la base del código del Modelo subyacente y su arquitectura, viceversa para el modelo.

Si sigues los podcasts de puedes escuchar a Jeff (y Geoff?) Hablar sobre su grandeza. http://blog..com/2008/08/podcast-17/ . Pero recuerde que el uso de estas capas separadas significa que las cosas son más fáciles en el futuro, y más difícil ahora. Y las capas pueden hacer las cosas más lentas. Y puede que no los necesites. Pero no dejes que eso te impida aprender de qué se trata. Al construir sistemas grandes, robustos y duraderos, es invaluable.

Una de las principales ventajas de MVC que no se menciona aquí es que MVC proporciona URLs RESTful que permiten SEO. Cuando nombra sus Controladores y Acciones con prudencia, hace que sea más fácil para los motores de búsqueda encontrar su sitio si solo examinan las URL de su sitio. Por ejemplo, tiene un sitio web de venta de automóviles y una página que muestra los automóviles Lamborghini Veneno disponibles, en lugar de tener www.MyCarSale.com/product/6548 refiriéndose a la página, puede elegir www.MyCarSale.com/SportCar/Lamborghini-Veneno url para Propósito de SEO

Here hay una buena respuesta a MVC Advantages y here hay un artículo Cómo crear una URL amigable con SEO.

Una desventaja en la que puedo pensar es si necesita acceso realmente rápido a sus datos en su vista (por ejemplo, datos de animación de juegos como posiciones de huesos). En este caso, es muy ineficiente mantener una capa de separación.

De lo contrario, para la mayoría de las otras aplicaciones que son más impulsadas por los datos que los gráficos, parece una forma lógica de conducir una IU.

MVC es solo un patrón de diseño general que, en el contexto del desarrollo de aplicaciones web lean, facilita al desarrollador mantener el marcado HTML en la capa de presentación de una aplicación (la vista) separada de los métodos que reciben y manejan las solicitudes de los clientes (el controladores) y las representaciones de datos que se devuelven dentro de la vista (los modelos). Se trata de la separación de preocupaciones, es decir, mantener el código que sirve para un propósito funcional (por ejemplo, el manejo de las solicitudes del cliente) secuestrado de un código que tiene un propósito funcional completamente diferente (por ejemplo, representar datos).

Es el mismo principio por el que cualquiera que haya pasado más de 5 minutos tratando de construir un sitio web puede apreciar la necesidad de mantener su marcado HTML, JavaScript y CSS en archivos separados: si solo coloca todo su código en un solo archivo, terminan con espagueti que es virtualmente no editable más adelante.

Como usted solicitó posibles "contras": no soy una autoridad en diseño de arquitectura de software, pero en base a mi experiencia en MVC, creo que también es importante señalar que seguir un patrón de diseño MVC estricto y sencillo es lo más útil para 1) aplicaciones web livianas, o 2) como la capa UI de una aplicación empresarial más grande. Me sorprende que no se hable más de esta especificación, ya que MVC no contiene definiciones explícitas para la lógica de su empresa, los modelos de dominio ni nada en la capa de acceso a datos de su aplicación. Cuando comencé a desarrollar en ASP.NET MVC (es decir, antes de saber que existían otras arquitecturas de software), terminaba con controladores muy inflados o incluso veía modelos llenos de lógica empresarial que, si hubiera estado trabajando en aplicaciones empresariales, tendría dificultó la modificación de otros desarrolladores que no estaban familiarizados con mi código (es decir, más espagueti).