MVC: ¿por qué la separación de modelo, vista y controlador?

Question

Aparte de los aspectos "filosóficos" de la misma, ¿es una mala idea que mi controlador también sea mi modelo?

Parece que ahorra algo de tiempo de programación. No tengo que crear lógica entre el controlador y el modelo, ya que es lo mismo. Y puedo interactuar directamente con la vista.

¿Cuál es el punto de separar el M y el C? ¿La única razón para separarlos es la modularidad, es decir, la capacidad de intercambiar un modelo y el controlador por otro? Me parece que "intercambiar" módulos pasa mucho menos que (por ejemplo) tener que actualizar tanto el modelo como el controlador porque algo en el modelo está cambiando.

---

Parece extraño que una simple calculadora, de acuerdo con el concepto de MVC, debe tener tanto un controlador y una vista para su configuración (como configuración predeterminada, o algo así). Sé que este es un ejemplo simple, pero parece aplicarse a todos los casos (excepto quizás a los marcos).

Answer 1

La razón principal es la reutilización del código. Si solo vas a escribir un programa en tu vida profesional, entonces tal vez no importe. Si planea hacer una carrera de eso, tener piezas reutilizables es valioso.El modelo bien diseñado, el controlador y las clases de vista son muy fáciles de incluir en otros programas. Hago esto todo el tiempo.

Considere UITableViewController, que es un controlador. Ahora imagínese si fue diseñado exclusivamente para manejar pistas de música (el Modelo), y necesitara crear una clase de administración de tablas completamente diferente cuando quisiera manejar algo más. Evitar esta pesadilla es la razón por la cual MVC se usa mucho en Cocoa.

Hay otras formas de dividir las cosas. Algunos idiomas subclasan mucho en lugar de delegar. Pero en Cocoa, el medio principal para dividir programas es MVC, y funciona muy bien.

EDIT: Solo algunas razones más del mundo del desarrollo de aplicaciones comerciales.

• La gestión de la memoria es mucho más fácil en MVC. Puede mantener sus objetos modelo y tirar sus objetos de visualización (y muchos de sus objetos de controlador) cuando se quedan fuera de la pantalla.

• Es más fácil serializar objetos modelo que no están envueltos con controladores y vistas, y es mucho más fácil mostrar los mismos datos de múltiples maneras. Incluso en un editor de texto "simple", es posible que desee poder hacer una pantalla dividida o tener varias ventanas que muestren el mismo documento. En MVC eso es muy fácil.

Si no necesita flexibilidad ahora o en el futuro, no necesita mucha arquitectura. Pero la mayoría de los proyectos reales no son tan simples. MVC surgió de la experiencia de Xerox en la redacción de programas de gran tamaño y las dificultades encontradas cuando todo se conjugaba.

---

EDIT 2: yo estaba buscando en su edición anterior: “Parece extraño que una simple calculadora, de acuerdo con el concepto de MVC, debe tener tanto un controlador y una vista para su configuración (como configuración predeterminada , o algo así). "

Esta es exactamente la razón para MVC. Parecería una locura tener que volver a codificar todas las cosas necesarias para guardar la configuración del usuario, especialmente para una aplicación de Calculadora. Desea una versión genérica "guarde esta configuración de usuario" que estaba completamente separada de la interfaz de usuario y que podría volver a utilizar. En OS X se llama NSUserDefaults, y la aplicación Calculator almacena su configuración exactamente de esta manera.

Answer 2

Si funciona para usted, entonces funciona. Período. El motivo de la separación de Modelos, Vistas y Controladores gira en torno a la idea de que la mayoría del desarrollo para aplicaciones empresariales lo realiza un equipo de desarrolladores.

Imagine 10 desarrolladores tratando de trabajar en su controlador. Pero todo lo que quieren hacer es agregar algo al modelo. Ahora su controlador se rompió? ¿Que hicieron?

Answer 3

Los modelos generalmente son componentes separados que se pueden reutilizar entre Controladores. Si usted es absolutamente seguro de que no volverá a utilizar Modelos en múltiples Controladores, realmente no veo un problema para combinar estas preocupaciones.

Supongo que se podría argumentar por qué incluso utilizar el diseño MVC si está planeando desviarse. Tal vez haya un patrón más adecuado a seguir para su situación. ¿Puede darnos un ejemplo de algo que haya hecho donde el Controlador es el Modelo? Nos ayudaría a entender lo que está tratando de hacer mejor.

Answer 4

MVC es un patrón estándar que se entiende bien en la comunidad de desarrollo, y por buenas razones. La separación realmente hace que las cosas sean fáciles de leer, fáciles de solucionar, fáciles de encontrar y fáciles de probar, como componentes individuales, cada uno con su propia área de responsabilidad.

¿Tienes que usarlo? por supuesto no. Pero mantener las partes separadas generalmente se considera una buena idea.

Answer 5

El controlador sabe cómo vincular una vista específica a su modelo. La separación de modelo y controlador, además de mejorar la documentación y la capacidad de mantenimiento, tiene el beneficio inmediato de permitir que múltiples vistas muestren la misma información del modelo sin agregar complejidad a ninguna de ellas.

Esto se aplica no solo a múltiples vistas en la misma aplicación, sino también a las múltiples variaciones en las vistas que tendrá en múltiples versiones de su aplicación. Su modelo está aislado y lógicamente limpio.

La combinación de modelo y controlador es una economía falsa clásica en mi opinión. Puede parecer que ahorra unos minutos, pero cuesta significativamente a medida que una aplicación se desarrolla y crece.

Answer 6

MVC tiene que ver con la gestión (separación de datos, representación y lógica comercial). Entonces es así: si tienes una empresa pequeña, tener una administración del tamaño de una MS sería una verdadera molestia. Pero si usted es una corporación gigante, no tener grandes mandos intermedios es imposible.

Honestamente, en la mayoría de mis asignaciones de programación universitaria, combiné los modelos y controladores, porque no veía la necesidad de la separación. ¿Pero trabajando en grandes proyectos? La deficiencia sería bastante obvia si intentas no separarte. Solo haz lo que te parezca correcto.

Answer 7

El modelo no depende de la vista ni del controlador. Este es uno de los beneficios clave de la separación. Esta separación permite que el modelo sea construido y probado independientemente de la presentación visual.