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

43

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.

Oscar Godson
la source
5
Il y a soit trop de réponses possibles, soit de bonnes réponses seraient trop longues pour ce format. Veuillez ajouter des détails pour affiner l’ensemble de réponses ou pour isoler un problème qui peut être résolu en quelques paragraphes.
Gnat
8
J'aurais besoin d'une réponse de votre définition de MVC avant de pouvoir répondre à votre question, car l'architecture MVC ne s'applique qu'à un ensemble de problèmes en l'état. Donc, si vous l'utilisez au mauvais endroit, vous perdez votre temps.
Ben McDougall
1
Quelle variété y a-t-il dans vos différents emplois?
JeffO
Lisez «MVC n'est pas orienté objet» .
mcintyre321
@JeffO applications PHP (backend, sites lourds non JS), applications frontales. Donc, tout le Web, mais front-end et backend.
Oscar Godson

Réponses:

46

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.

Hedin
la source
10
en réalité, vous pouvez implémenter MVC à tout moment si vous avez une couche d'abstraction; l'API est la vue / contrôleur et la logique sous-jacente est le modèle
ratchet freak
14
@ratchetfreak, techniquement parlant, une API est une forme d'interface utilisateur, où l'utilisateur est le programmeur utilisant l'API.
zzzzBov
@ratchetfreak: cela ne serait-il pas classé comme motif de façade?
Jeroen Vannevel
2
MVC peut être plus utile dans l'interface utilisateur, mais sa séparation des préoccupations n'est pas seulement utile là.
DougM
1
@DougM true. plus précisément: le style de séparation spécifique dans MVC a été créé pour les applications à interface graphique. plus tard, le concept a été étendu aux applications Web, perdant beaucoup de spécificité. l’étendre davantage aux conceptions d’API le rend encore plus vague. au-delà ... je pense qu'il perd la plus grande partie de sa valeur et qu'il serait préférable de recommencer à zéro avec le concept plus fondamental (et universel) de la séparation des préoccupations.
Javier
17

À 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:

entrez la description de l'image ici

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.

Doctorat
la source
+1 pour "pur vs impur". Bien que je préfère utiliser "interface graphique vs Web MVC", et souligne que l'interface graphique MVC est modulaire tandis que Web MVC est en couches . J'aimerais vraiment que le Web MVC s'appelle autre chose, car il est trop différent du "pur MVC", mais il semble qu'il soit trop tard pour cela.
Javier
J'aime le diagramme. Ré. la formulation, peut-être "traditionnel MVC vs dérivé MVC" :)
Edwin Yip
12

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.

Robbie Dee
la source
2
MVC, s'il est correctement suivi, permet la réutilisation du code. la même logique que celle d'un projet utilitaire ou en ligne de commande peut facilement être un contrôleur identique issu d'un programme plus volumineux avec un modèle et une vue alternatifs. (Ce n'est peut-être pas le code le plus efficace, mais ce n'est pas toujours un problème.)
DougM
La console est une interface utilisateur. Juste basé sur le texte, donc votre hypothèse est fausse.
GuardianX
@ GuardianX Je n'ai pas vraiment dit ce mot très bien. J'ai modifié ma réponse pour clarifier.
Robbie Dee
3

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.

DougM
la source
+1 pour mentionner des projets plus petits bien que j'apprécie qu'il existe différentes écoles de pensée ici. Certains diront que s'il y a une chance qu'un POC puisse évoluer en code live, il devrait être écrit correctement. Tandis que d'autres disent que plutôt que de risquer de perdre du temps à polir quelque chose qui ne pourrait jamais être utilisé, il serait préférable d'ébaucher quelque chose ensemble et de recommencer si le projet avance.
Robbie Dee
@Robbie: ahh !! fonctionnalité ramper!
DougM
0

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.

Rex
la source