¿Cuáles son las desventajas de MVC? [cerrado]

He estado usando MVC / MV * desde que comencé a organizar mi código hace años. Lo he estado usando tanto tiempo que ni siquiera puedo pensar en otra forma de estructurar mi código y cada trabajo que tuve después de ser pasante estaba basado en MVC.

Mi pregunta es, ¿cuáles son las caídas de MVC? ¿En qué casos MVC sería una mala elección para un proyecto y cuál sería la opción (más) correcta? Cuando busco alternativas de MVC, casi todos los resultados son solo diferentes tipos de MVC.

Para reducir el alcance para que esto no se cierre, digamos para las aplicaciones web. Trabajo en el backend y front-end para diferentes proyectos, por lo que no puedo decir solo front-end o back-end.

Siempre debe recordar: MVC es un patrón relacionado con la interfaz de usuario. Si está creando una aplicación compleja, debe sacar todo, que no esté relacionado con la interfaz de usuario, de los tripletes MVC a cualquier otra clase, subsistema o capa.

Fue mi mayor error. Pasé mucho tiempo entendiendo esa simple regla:

• No difunda un patrón MVC entre toda la aplicación,
• Limítelo solo a cosas relacionadas con la interfaz de usuario.

Compruebe siempre si el código que escribe está lógicamente en el lugar correcto, lo que significa que encaja lógicamente en su área de responsabilidad de la clase en la que lo coloca. Si no es así, retire el código tan pronto como lo entienda.

Todos los patrones que llama alternativas MVC (es decir, Model-View-Presenter, Model-View-ViewModel) son solo una forma de implementar el concepto general de MVC.

En mi opinión, hay dos tipos de MVC: puro e impuro (por falta de una palabra mejor :)

MVC puro es lo que se introdujo en una pequeña charla:

Esto estaba destinado a la informática personal / aplicaciones de escritorio. Como puede ver, el modelo informa las vistas de cualquier actualización / cambio realizado. No es así con (impuro) MVC.

El otro MVC (impuro) que se promociona para aplicaciones web es más un patrón PAC ( Presentation-abstraction-control ) en lugar del clásico MVC anterior. Eso es más sobre la organización del código y la separación de preocupaciones:

• Modelo : abstracción para datos almacenados
• Control : por lo general, lo que se conoce como la capa de lógica de negocios, así como parte de la aplicación responsable de enrutar las solicitudes HTTP a la lógica de negocios correspondiente (también conocido como controlador)
• Ver : en su mayoría, ver plantillas que formatean los datos del modelo y los devuelven al cliente. El modelo NUNCA envía actualizaciones a la vista ni la vista se 'suscribe' para recibir actualizaciones de un modelo. Sería una pesadilla de acoplamiento. Por lo tanto, se parece más a PAC que a MVC verdadero.

Ahora, así es como generalmente se estructura una aplicación web:

1. Front-end : MVC en el cliente usando frameworks como Backbone.js, etc., esta es la forma 'verdadera' de MVC en esencia.
2. Back-end : una vez más, usted tiene (impuro) MVC / PAC para la organización del código y la separación de preocupaciones
3. Aplicación web global (para la aplicación web en su conjunto): si tiene un backend RESTful que solo devuelve datos JSON, entonces todo su backend puede ser percibido como un modelo para la aplicación cliente front-end donde residen esencialmente View y Controller.

Entonces, ¿cuáles son algunas desventajas de MVC ? Bueno, el patrón ha resistido la prueba del tiempo, por lo que no hay muchos que importen mucho más que ser un poco "complicado". Verá, el MVC es un patrón compuesto: implementa un patrón de estrategia / observador y todos están bien organizados para formar un patrón de alto nivel.

¿Deberías usarlo en todas partes? Tal vez no. ¡Las aplicaciones web extremadamente complejas pueden dividirse en varias capas! Es posible que no pueda escapar solo con las capas Ver / Lógica empresarial / Datos. El marco / organización general aún puede ser MVC-ish, pero solo a nivel macroscópico.

Aquí hay un ejemplo en el que solo MVC en sí mismo puede ser una mala opción : intente diseñar un sistema de control de tráfico aéreo o una aplicación de procesamiento de préstamos / hipotecas para un banco grande; solo MVC en sí mismo sería una mala opción. Inevitablemente, tendrá buses de eventos / colas de mensajes junto con una arquitectura de varias capas con MVC dentro de capas individuales y posiblemente un diseño general de MVC / PAC para mantener la base de código mejor organizada.

El error que mucha gente comete con los patrones de diseño es ver que funciona maravillosamente en un lugar y luego tratar de aplicarlo en todas partes.

Si ha trabajado en un lugar durante un tiempo, casi puede fechar un código al ver qué tecnologías / patrones de diseño / prácticas estaban de moda en ese momento, por ejemplo, singletons / inyección de dependencia / TDD, etc.

En cuanto a dónde no usarlo. Bueno, donde no se aplique un elemento del triplete MVC. Las aplicaciones de consola pueden no implementar una interfaz en absoluto. Los programas de utilidad pueden no tener un modelo. Y podría decirse que si no tiene un modelo ni una vista, no necesita un controlador.

El problema rara vez está en el concepto, más en la implementación. No importa cuán bueno sea el paradigma, tómese el tiempo para ver si es adecuado para el problema en cuestión.

MVC, como cualquier paradigma que no es integral a su plataforma de desarrollo, es una mayor complejidad. Su inconveniente es que puede terminar separando clases que no deberían estar separadas, y disminuyendo la claridad de cuán estrechamente vinculadas están. (O, para proyectos triviales, incluso ofuscar su código).

La alternativa para el primer problema es separar dicho código en subproyectos independientes; La alternativa para el segundo es el código no separado, ya sea en la clase o en el modelo de archivo.

Mi comprensión de la aplicación de MVC / MV * sigue el principio de Separación de preocupaciones (SoC): separar el programa / códigos en secciones / piezas distintas para que cada sección pueda abordar una preocupación por separado (Ref: http://en.wikipedia.org / wiki / Separation_of_concerns )

Hay muchas ventajas al separar las preocupaciones: una no afectará a la otra y los desarrolladores podrían trabajar en una unidad sin afectar al resto, etc., etc. MVC no es el único patrón que sigue a SoC, básicamente, la POO en sí misma es Un gran concepto para dividir las cosas en unidades.

MVC / MV * son muy útiles cuando maneja el desarrollo relacionado con la interfaz de usuario, mientras que debajo podría haber más patrones: fábrica, singleton, fachada, etc. algunos casos. Es posible que vea mucho MVC, porque muchos proyectos tienen elementos de interfaz de usuario.

por lo tanto, al hablar de los inconvenientes de MVC, realmente depende de los proyectos que esté haciendo: ¿tiene UI? ¿Requiere gran escalabilidad / extensibilidad? ¿Tiene muchas interacciones entre la interfaz de usuario y el sistema subyacente? por ejemplo, una página web de información simple no requiere MVC en absoluto, a menos que planee extenderla a una gran página interactiva en el futuro.

entonces, para evaluar MVC (o más general - un patrón de diseño), darle un contexto y pensar en la complejidad, escalabilidad, capacidad de prueba, mantenimiento, restricción de tiempo, etc., etc.