Quels sont les inconvénients de MVC?
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 façon de structurer mon code et chaque travail que j'ai eu après avoir été stagiaire était basé sur MVC.
Ma question est, quels sont les inconvénients de MVC? Dans quels cas MVC serait-il un mauvais choix pour un projet et quel serait le (plus) bon choix? Lorsque je recherche des alternatives MVC, presque tous les résultats ne sont que des types différents de MVC.
Pour réduire la portée afin que cela ne soit pas fermé, disons pour les applications Web. Je travaille sur le backend et le front-end pour différents projets, donc je ne peux pas dire juste front-end ou backend.
Vous devez toujours vous souvenir - MVC est un modèle lié à l'interface utilisateur. Si vous construisez une application complexe, vous devez prendre tout ce qui n'est pas lié à l'interface utilisateur, des triplets MVC à d'autres classes, sous-systèmes ou couches.
Ce fut ma plus grosse erreur. J'ai passé beaucoup de temps à comprendre cette règle simple:
- Ne répartissez pas un modèle MVC sur 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 s'inscrit logiquement dans son 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 d'implémenter le concept général MVC.
À mon avis, il existe deux types de MVC - purs et impurs (faute d'un meilleur mot :)
Pure MVC est ce qui a été introduit dans les petites discussions:
Il était destiné aux applications informatiques/de bureau personnelles. Comme vous pouvez le voir, le modèle informe les vues des mises à jour/modifications qui y sont apportées. Ce n'est pas le cas avec MVC (impur).
L'autre MVC (impur) qui est vanté pour les applications Web est plus un modèle PAC ( Presentation-abstraction-control ) au lieu du MVC classique ci-dessus. C'est plus de l'organisation du code et la séparation des préoccupations:
- Modèle : Abstraction pour les données stockées
- Contrôle : généralement ce qu'on appelle la couche de logique métier ainsi qu'une partie de l'application responsable du routage des requêtes HTTP vers la logique métier correspondante (aka contrôleur )
- Affichage : affiche principalement des modèles qui mettent en forme les données du modèle et les renvoient au client. Le modèle n'envoie JAMAIS de mises à jour à la vue et la vue ne s'abonne pas aux mises à jour d'un modèle. Ce serait coupler le cauchemar. Par conséquent, cela ressemble plus à PAC qu'à vrai MVC.
Maintenant, voici comment une application Web est généralement structurée:
- Front-end : MVC sur le client utilisant des frameworks comme Backbone.js etc.
- Back-end : Encore une fois, vous avez (impur) MVC/PAC pour l'organisation du code et la séparation des préoccupations
- Application Web globale (pour l'application Web dans son ensemble): Si vous avez un backend RESTful qui ne renvoie que des données JSON, alors tout votre backend peut être perçu comme a model pour l'application cliente frontale où la vue et le contrôleur résident essentiellement.
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 comptent à part ça, c'est un peu "compliqué". Vous voyez, le MVC est un modèle composé - met en œuvre un modèle de stratégie/observateur et tous sont bien disposés pour former un modèle de haut niveau.
Devriez-vous l'utiliser partout? Peut-être pas. Les applications Web extrêmement complexes peuvent être divisées en plusieurs couches! Vous ne pourrez peut-être pas vous en sortir avec seulement les couches View/Business Logic/Data. Le cadre/organisation global peut encore être MVC-ish, mais seulement à un niveau macroscopique.
Voici un exemple où juste MVC en soi peut être un mauvais choix: Essayez de concevoir un système de contrôle du trafic aérien ou une application de traitement de prêt/hypothèque pour une grande banque - juste MVC en soi serait un mauvais choix. Vous aurez inévitablement des bus d'événements/des files d'attente de messages ainsi qu'une architecture multicouche avec MVC dans des couches individuelles et éventuellement une conception globale MVC/PAC pour garder la base de code mieux organisée.
L'erreur que beaucoup de gens font avec les modèles de conception est de voir que cela fonctionne magnifiquement en un seul endroit, puis d'essayer de l'appliquer partout.
Si vous avez travaillé au même endroit pendant un certain temps, vous pouvez presque dater un morceau de code en voyant quelles technologies/modèles de conception/pratiques étaient en vogue à l'époque, par exemple singletons/injection de dépendances/TDD etc etc.
Quant à savoir où ne pas l'utiliser. Eh bien, partout où un élément du triplet MVC ne s'applique pas. Les applications de console peuvent ne pas implémenter du tout une interface. 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 - plus à la mise en œuvre. Peu importe la qualité du paradigme, prenez le temps de voir s'il est bien adapté au problème en cours.
MVC, comme tout paradigme non intégré à votre plateforme de développement, est une complexité accrue. Son inconvénient est que vous pouvez terminer des classes séparées qui ne devraient pas être séparées, et diminuer la clarté de leur lien. (Ou, pour des projets triviaux, même pour brouiller votre code.)
L'alternative pour le premier problème est de séparer ce code en sous-projets indépendants; l'alternative pour le second est un code non séparé, soit au niveau du modèle de classe ou de fichier.
Ma compréhension de l'application de MVC/MV * suit le principe de la séparation des préoccupations (SoC) - la séparation des programmes/codes en sections/morceaux distincts afin que chaque section puisse répondre à une préoccupation distincte (Réf: http: // en .wikipedia.org/wiki/Separation_of_concerns )
il y a beaucoup d'avantages à séparer les préoccupations: l'une n'affectera pas l'autre et les développeurs pourraient travailler sur une unité sans affecter le reste, etc. & etc ... MVC n'est pas le seul modèle qui suit SoC, fondamentalement, OOP lui-même est 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, tandis qu'en dessous, il pourrait y avoir plus de modèles - usine, singleton, façade, etc. La majorité des grands projets se composent de plusieurs couches gérant différents aspects, mais l'interface utilisateur peut ne pas être un must certains cas. Vous pouvez voir beaucoup de MVC - c'est parce que beaucoup de projets ont des éléments d'interface utilisateur.
ainsi, tout en parlant des inconvénients de MVC, cela dépend vraiment des projets que vous faites - a-t-il une interface utilisateur? nécessite-t-il une grande évolutivité/extensibilité? a-t-il de nombreuses interactions entre l'interface utilisateur et le système arrière? par exemple, une simple page Web d'informations ne nécessite pas du tout de MVC, sauf si vous prévoyez de l'étendre à une grande page interactive à l'avenir.
donc afin d'évaluer MVC (ou plus généralement - un modèle de conception), lui donner un contexte et penser à la complexité, l'évolutivité, la testabilité, la maintenance, la contrainte de temps, etc. & etc.