¿Por qué debería usar un patrón MVC?

Parece que todos los que hacen aplicaciones web hoy en día quieren usar MVC para todo. Sin embargo, me resulta difícil convencerme de usar este patrón. Entiendo que la idea general es separar la lógica del backend de la interfaz que representa el programa. En general, parece que las vistas siempre dependen en cierta medida del controlador, lo que termina dependiendo del modelo. No veo qué ventaja me da agregar el controlador. He leído muchas exageraciones sobre "esta es la forma en que deberían diseñarse las aplicaciones", pero tal vez todavía no entiendo qué se supone que debe ir a dónde. Cada vez que hablo con otros sobre MVC parece que todos tienen una idea diferente de qué pertenece en qué categoría.

Entonces, ¿por qué debería usar MVC? ¿Qué gano usando MVC en lugar de separar la interfaz de la lógica de back-end? (La mayoría de las "ventajas" que veo de este patrón se obtienen simplemente separando la interfaz de la implementación, y no explican el propósito de tener un "controlador" separado)

Je Martin Fowler está de acuerdo con su confusión sobre MVC:

No me resulta terriblemente útil pensar en MVC como un patrón porque contiene bastantes ideas diferentes. Diferentes personas que leen sobre MVC en diferentes lugares toman diferentes ideas y las describen como 'MVC'. Si esto no causa suficiente confusión, entonces obtienes el efecto de malentendidos de MVC que se desarrollan a través de un sistema de susurros chinos.

Sin embargo, continúa dando una de las explicaciones más convincentes de lo que motiva a MVC:

En el corazón de MVC está lo que llamo presentación separada. La idea detrás de la presentación separada es hacer una división clara entre los objetos de dominio que modelan nuestra percepción del mundo real y los objetos de presentación que son los elementos de la GUI que vemos en la pantalla. Los objetos de dominio deben ser completamente autónomos y funcionar sin referencia a la presentación, también deben ser capaces de soportar múltiples presentaciones, posiblemente simultáneamente.

Puedes leer el artículo completo de Fowler aquí .

Siento que esto depende mucho del problema que estés abordando. Veo la separación de la siguiente manera:

Modelo : ¿cómo representamos los datos? Por ejemplo, ¿cómo paso de mis objetos a un almacenamiento persistente como un DB -> cómo guardo mi objeto 'Usuario' en la base de datos?

Controlador : ¿qué estoy haciendo? Esta es la acción que está teniendo lugar y lo que, en un nivel conceptual, debe llevarse a cabo. Por ejemplo, ¿qué etapas debo atravesar para facturar a un usuario? Nota: esto puede afectar cualquier cantidad de objetos, pero no sabe nada acerca de cómo se mantienen en la base de datos.

Ver : ¿cómo renderizo el resultado?

El problema que siento que está viendo es que muchas aplicaciones web son una interfaz CRUD (Crear-Recuperar-Actualizar-Eliminar) glorificada para un DB. es decir, se le dice al controlador que 'agregue un usuario', y luego simplemente le dice al modelo que 'agregue un usuario'. No se gana nada.

Sin embargo, en los proyectos donde las acciones que lleva a cabo no se aplican directamente a los cambios en el modelo, un controlador facilita mucho la vida y hace que el sistema sea más fácil de mantener.

No deberías

Déjame reformular eso. Debe usar una arquitectura que separe la lógica de sus vistas. Si es necesario, debe usar una arquitectura que utilice un controlador (como MVC) si se requiere una lógica que no necesariamente se ajuste a un modelo (como, por ejemplo, un fragmento de URL de análisis transversal del árbol).

Viniendo de CI y Yii, pensé que tener un controlador dedicado era una idea genial. Sin embargo, cuando se desarrollan aplicaciones con interfaces RESTful adecuadas, la necesidad de un controlador para manejar la lógica no específica del modelo parece disminuir. Por lo tanto, cuando me mudé a Django y luego a Pyramid (ninguno de los cuales sigue la arquitectura MVC por completo), descubrí que el controlador no era realmente un componente requerido para las aplicaciones que estaba creando. Tenga en cuenta que ambos marcos tienen características "controlador'ish", como el envío de URL en Pyramid, pero es una cuestión de configuración, no una cuestión de tiempo de ejecución (como CController en Yii).

Al final del día, lo que es realmente importante es la separación de la vista de la lógica. Esto no solo limpia las cosas en términos de implementación, sino que también permite que los ingenieros de FE / BE trabajen en paralelo (cuando trabajan en un entorno de equipo).

(Nota al margen: no desarrollo aplicaciones web profesionalmente, por lo que puede haber algo que me falta)

Sí, la terminología de esto es un desastre. Es difícil hablar porque nunca entiendes lo que alguien quiere decir con los términos.

En cuanto a por qué un controlador separado, la razón puede depender de la versión del controlador del que se habla.

Es posible que desee un controlador porque cuando ejecuta pruebas, la vista tiene un montón de widgets que no escribió y probablemente no desea probar. Sí, separó la implementación de la herencia, por lo que puede usar un trozo o simulación para probar otras cosas, pero cuando prueba su vista concreta en sí misma, es más difícil. Si tuvieras un controlador que no tuviera widgets ejecutando el mismo código, entonces podrías probarlo directamente, y tal vez no necesites probar los widgets a través de un script.

En mi humilde opinión, las otras versiones son más difíciles de mostrar para un beneficio concreto. Creo que es principalmente un problema de separación de preocupaciones: separe las preocupaciones de la GUI visual pura de la lógica que se aplica a la GUI pero que no forma parte del modelo de negocio (cosas como traducir actualizaciones del modelo en el que los widgets deberían estar visibles). Pero en la práctica, es probable que las dos clases estén tan estrechamente acopladas (incluso si se comunican a través de las interfaces) que es difícil estar demasiado molesto al fusionarlas en una sola vista, y solo estar atento a las formas en que la funcionalidad podría ser más reutilizable si estuvieran divididos

En pocas palabras: separación de preocupaciones. Además de todo lo que se habla sobre la forma "correcta" de hacer las cosas, tener un código más limpio, etc., puede decir que MVC le permite reutilizar su código más fácilmente. Básicamente, usted programa sus modelos y sus controladores y puede usarlos indistintamente en una aplicación web, una aplicación de escritorio, un servicio, en cualquier lugar sin mucho esfuerzo.

Bueno, la razón básica para usar una estructura MVC aparece en una configuración de la industria, donde un solo proceso de trabajo, se sigue un solo modelo para el desarrollo de cualquier aplicación. Entonces, en caso de que el proyecto pase de un módulo de una organización a otro, es mucho más fácil proporcionar una mejor comprensión del escenario de trabajo. Incorpora claridad de trabajo.
Mientras que usted, como individuo, tendría un enfoque diferente para su aplicación, cuando trabaje de manera combinada con un asociado, primero debatiría y aterrizaría sobre un modelo comúnmente acordado por los dos (usted y su asociado). Y en tal caso, separa las responsabilidades asignadas a usted y su asociado, respectivamente, con un margen distintivo.

Creo que MVC se usa solo como una palabra de moda por los teóricos que son gerentes. Sin embargo, una vez dicho esto, la iteración actual de la web con un diseño HTML5 frecuente y receptivo, y el intento de crear una sola línea de programación de bases de datos que funcione en la web y en un iPhone se presta a las ideas generales de MVC. La tecnología front-end web se está moviendo literalmente a la velocidad de la luz en este momento con Jquery, nuevas iteraciones de control CSS, mientras que el lado del servidor se mueve al ritmo de un caracol.

Eventualmente, todo en el servidor será solo servicios o "applets" que bombearán los datos al front-end y, dependiendo del tipo de cliente que tenga, esos datos se consumirán y se mostrarán de manera diferente. En ese sentido, MVC tiene sentido.

A este respecto, creo en el mundo real actual, el MVVM es realmente un "patrón" mejor o como quiera llamarlo que un controlador porque un controlador siempre tiene que volver al modelo para cambiar la vista y esto es lento . En el patrón MVVM, ViewModel puede proporcionar actualizaciones inmediatas a la vista. Además, el modelo MVVM promueve los principios de diseño RESTful en mi humilde opinión.