Quels sont les inconvénients de MVC? [fermé]

J'utilise MVC / MV * depuis que j'ai commencé à organiser mon code il y a des années. Je l'utilise depuis si longtemps que je ne peux même pas penser à une autre manière de structurer mon code et chaque travail que j'ai eu après avoir été stagiaire était basé sur MVC.

Ma question est la suivante: quels sont les inconvénients de MVC? Dans quels cas MVC serait-il un mauvais choix pour un projet et quel serait le choix correct (le plus correct)? Lorsque je recherche des alternatives MVC, presque tous les résultats correspondent à différents types de MVC.

Pour limiter la portée afin qu'elle ne soit pas fermée, disons pour les applications Web. Je travaille sur le backend et le front-end pour différents projets, donc je ne peux pas dire simplement front-end ou back-end.

N'oubliez jamais que MVC est un modèle associé à l'interface utilisateur. Si vous construisez une application complexe, vous devez prendre tout ce qui n’est pas lié à l’UI, des triplets MVC à d’autres classes, sous-systèmes ou couches.

C'était ma plus grosse erreur. J'ai passé beaucoup de temps à comprendre cette règle simple:

• Ne répandez pas de motif MVC dans l’ensemble de l’application,
• Limitez-le aux éléments liés à l'interface utilisateur uniquement.

Vérifiez toujours si le code que vous écrivez est logiquement au bon endroit, ce qui signifie qu’il entre logiquement dans le domaine de responsabilité de la classe dans laquelle vous le placez. Sinon, éloignez le code dès que vous le comprenez.

Tous les modèles que vous appelez les alternatives MVC (c'est-à-dire Model-View-Presenter, Model-View-ViewModel) ne sont qu'un moyen de mettre en œuvre le concept général de MVC.

À mon avis, il existe deux types de MVC - pur et impur (faute d'un meilleur mot :)

Pure MVC est ce qui a été introduit dans les petites discussions:

Ceci était destiné aux applications informatiques personnelles / de bureau. Comme vous pouvez le constater, le modèle informe les vues de toutes les mises à jour / modifications apportées. Pas si avec MVC (impur).

L'autre MVC (impur) vanté pour les applications Web est davantage un motif PAC ( Presentation-abstraction-control ) plutôt que le MVC classique ci-dessus. C'est plus de l'organisation du code et de la séparation des préoccupations:

• Modèle : Abstraction pour les données stockées
• Contrôle : généralement appelé couche de logique métier et partie de l'application chargée de router les demandes HTTP vers la logique métier correspondante (contrôleur).
• Vue : affiche principalement les modèles qui formatent les données du modèle et les renvoient au client. Le modèle n'envoie JAMAIS de mises à jour à la vue, pas plus que la vue ne s'abonne aux mises à jour d'un modèle. Ce serait un cauchemar couplé. Par conséquent, cela ressemble plus à du PAC qu'au vrai MVC.

Maintenant, voici comment une application Web est généralement structurée:

1. Interface frontale : MVC sur un client utilisant des frameworks tels que Backbone.js, etc., Il s'agit essentiellement du "vrai" formulaire MVC.
2. Back-end : Encore une fois, vous avez (impur) MVC / PAC pour l'organisation du code et la séparation des problèmes
3. Application Web globale (pour l'application Web dans son ensemble): Si le backend RESTful renvoie uniquement des données JSON, l'intégralité de celui-ci peut être perçu comme un modèle pour l'application client frontale où résident essentiellement View et Controller.

Alors, quels sont les inconvénients de MVC ? Eh bien, le modèle a résisté à l'épreuve du temps, donc il n'y en a pas beaucoup qui importent moins que cela soit un peu "compliqué". Vous voyez, le MVC est un modèle composé - implémente un modèle stratégie / observateur et tous sont bien agencés pour former un modèle de haut niveau.

Devez-vous l'utiliser partout? Peut être pas. Des applications Web extrêmement complexes peuvent être divisées en plusieurs couches! Vous ne pourrez peut-être pas vous contenter des couches View / Business Logic / Data. Le cadre / l’organisation globale peut encore être MVC-ish, mais seulement à un niveau macroscopique.

Voici un exemple où MVC en lui-même est peut-être un mauvais choix : essayez de concevoir un système de contrôle du trafic aérien ou une application de traitement des emprunts / des prêts hypothécaires pour une grande banque; juste en fait, MVC serait un mauvais choix. Vous aurez inévitablement des bus d'événements / des files de messages avec une architecture multicouche avec MVC au sein de couches individuelles et éventuellement une conception globale MVC / PAC pour mieux organiser la base de code.

L'erreur que beaucoup de gens font avec les modèles de conception est de constater que cela fonctionne à merveille dans un endroit et d'essayer de l'appliquer partout.

Si vous avez travaillé à un endroit pendant un certain temps, vous pouvez presque dater un morceau de code en observant quelles technologies / modèles / pratiques de conception étaient à la mode à l'époque, par exemple, singletons / dépendance, injection / TDD, etc.

Quant à savoir où ne pas l'utiliser. Eh bien, chaque fois qu'un élément du triplet MVC ne s'applique pas. Les applications de console peuvent ne pas implémenter une interface du tout. Les programmes utilitaires peuvent ne pas avoir de modèle. Et sans doute, si vous n’avez ni modèle ni vue, vous n’avez pas besoin d’un contrôleur.

Le problème est rarement lié au concept, mais plutôt à la mise en œuvre. Peu importe la qualité du paradigme, prenez le temps de voir si cela convient au problème à résoudre.

MVC, comme tout paradigme ne faisant pas partie intégrante de votre plate-forme de développement, est une complexité accrue. Son inconvénient est que vous pouvez vous retrouver avec des classes séparées qui ne devraient pas être séparées, et une clarté décroissante de leur degré de consolidation. (Ou, pour des projets triviaux, même obscurcir votre code.)

L’autre solution au premier problème consiste à séparer ce code en sous-projets indépendants; l'alternative pour le second est le code non séparé, au modèle de classe ou de fichier.

Ma compréhension de l’application de MVC / MV * suit le principe de la séparation des problèmes (SoC): séparer les programmes / codes en sections / éléments distincts de sorte que chaque section puisse traiter d’un problème distinct (Réf: http://en.wikipedia.org / wiki / Separation_of_concerns )

il existe de nombreux avantages à séparer les préoccupations: les unes n'affectent pas les autres et les développeurs peuvent travailler sur une unité sans impacter le reste, etc. & etc ... MVC n'est pas le seul modèle qui suive SoC; un excellent concept pour diviser les choses en unités.

MVC / MV * sont très utiles lorsque vous gérez le développement lié à l'interface utilisateur, alors qu'il pourrait y avoir davantage de modèles - usine, singleton, façade, etc. La plupart des grands projets sont constitués de plusieurs couches gérant différents aspects, certains cas. Vous voyez souvent MVC, car de nombreux projets comportent des éléments d'interface utilisateur.

Ainsi, tout en parlant des inconvénients de MVC, cela dépend vraiment des projets que vous réalisez - a-t-il une interface utilisateur? faut-il une grande évolutivité / extensibilité? a-t-il de nombreuses interactions entre l'interface utilisateur et le système postérieur? Par exemple, une simple page Web d'informations n'exige pas du tout MVC, sauf si vous envisagez de l'étendre ultérieurement à une excellente page interactive.

donc pour évaluer MVC (ou plus généralement - un modèle de conception), lui donner un contexte et réfléchir à la complexité, à l’évolutivité, au testable, à la maintenance, aux contraintes de temps, etc. & etc.