¿Por qué debo usar un patrón MVC?

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

  

No me parece terriblemente útil pensar en MVC como un patrón porque   Contiene bastantes ideas diferentes. Diferentes personas leyendo   acerca de MVC en diferentes lugares toma diferentes ideas de él y   describir estos como 'MVC'. Si esto no te causa suficiente confusión   a continuación, obtener el efecto de malentendidos de MVC que se desarrollan a través de una   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 clara división entre   objetos de dominio que modelan nuestra percepción del mundo real, y   Objetos de presentación que son los elementos GUI que vemos en la pantalla.   Los objetos de dominio deben ser completamente autónomos y trabajar sin   referencia a la presentación, también deben ser capaces de apoyar   Presentaciones múltiples, posiblemente simultáneas.

Puede 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 puedo pasar 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 se está llevando a cabo y lo que, a nivel conceptual, debe llevarse a cabo. Por ejemplo, ¿qué etapas debo pasar para facturar a un Usuario? nótese bien esto puede afectar a cualquier cantidad de objetos, pero no sabe nada sobre cómo se conservan en la base de datos.

Ver : ¿cómo puedo representar el resultado?

El problema que siento que estás viendo es que muchas aplicaciones web son una interfaz glorificada de CRUD (Crear-Recuperar-Actualizar-Eliminar) para una base de datos. 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 en los que las acciones que realiza no se aplican directamente a los cambios en el modelo, un controlador hace que la vida sea mucho más fácil y que el sistema sea más mantenible.

No deberías.

Déjame reformular eso. Debe utilizar 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 se ajuste necesariamente a un modelo (como, por ejemplo, un fragmento de URL de análisis transversal de árbol).

Viniendo de CI y Yii, pensé que tener un controlador dedicado era una idea realmente genial. Sin embargo, al desarrollar 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 "controladoras", como el envío de URL en Pyramid, pero es una cuestión de configuración, no de tiempo de ejecución (como CController en Yii).

Al final del día, lo que realmente es 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 a los ingenieros de FE / BE trabajar en paralelo (cuando se trabaja en un entorno de equipo).

(Nota al margen: no desarrollo aplicaciones web profesionalmente, así que puede que falte algo)

Sí, la terminología sobre esto es un desastre. Es difícil hablar de eso porque nunca entiendes lo que significa por los términos.

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

Es posible que desee un controlador porque cuando ejecuta las pruebas, la vista tiene un montón de widgets que no escribió y que probablemente no desea probar. Sí, separaste la implementación de la herencia, así que puedes usar un talón o simulacro para probar otras cosas, pero cuando pruebas tu vista concreta en sí es más difícil. Si tuviera un controlador que no tuviera widgets que ejecutaran el mismo código, entonces podría probarlo directamente, y tal vez no necesitar probar los widgets a través de un script.

Las otras versiones son IMHO más difíciles de mostrar para un beneficio concreto. Creo que es principalmente un problema de separación de inquietudes: separar las inquietudes de la GUI visuales puras de la lógica que se aplica a la GUI pero no es parte del modelo de negocio (por ejemplo, traducir las actualizaciones del modelo a las que los widgets deben ser 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 interfaces) que es difícil estar demasiado molesto por fusionarlas en solo una 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. Aparte de toda la charla sobre la manera "correcta" de hacer las cosas, tener un código más limpio, etc., simplemente puede decir que MVC le permite reutilizar su código más fácilmente. Básicamente, programa sus modelos y sus controladores y puede utilizarlos 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 se muestra en una configuración de la industria, donde en 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 discutirá y aterrizará en un modelo comúnmente acordado por los dos (usted y su asociado). Y en tal caso, separa las responsabilidades asignadas a usted y a su asociado, respectivamente, con un margen distintivo.

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

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

En este sentido, creo que en el mundo real actual, el MVVM es realmente un "patrón" mejor o lo que 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, el ViewModel puede dar actualizaciones inmediatas a la vista. Además, el modelo MVVM promueve los principios de diseño RESTful IMHO.