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

72

Parece que todos los que hacen aplicaciones web hoy en día quieren usar MVC para todo. Sin embargo, me cuesta convencerme de usar este patrón. Entiendo que la idea general es separar la lógica de backend de la interfaz que representa el programa. En general, parece que las vistas siempre dependen del controlador en cierta medida, 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 deben 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 lo que pertenece a qué categoría.

Entonces, ¿por qué debería usar MVC? ¿Qué gano al usar MVC al separar el frontend de la lógica de backend? (La mayoría de las "ventajas" que veo de este patrón se obtienen simplemente al separar la interfaz de la implementación, y no puedo explicar el propósito de tener un "controlador" separado)

    
pregunta Billy ONeal 01.09.2011 - 20:53

7 respuestas

48

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í .

    
respondido por el Gnawme 01.09.2011 - 21:37
18

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.

    
respondido por el Unk 01.09.2011 - 21:08
7

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)

    
respondido por el Demian Brecht 01.09.2011 - 21:06
1

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.

    
respondido por el psr 02.09.2011 - 01:06
0

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.

    
respondido por el AJC 01.09.2011 - 21:49
-3

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.

    
respondido por el ikartik90 01.09.2011 - 21:29
-3

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.

    
respondido por el Michael Barber 08.05.2015 - 20:41

Lea otras preguntas en las etiquetas