Quels sont les principaux avantages du modèle MVC sur l'ancienne configuration 3 couches

Question

Je contemplait sur l'utilisation d'un modèle MVC dans mon nouveau projet et je peux voir clairement l'avantage d'être en mesure de mettre la couche de données (le modèle) un peu plus proche de la couche de présentation (la vue), ce qui permettra une faible augmentation de la vitesse d'application. Mais en dehors du point de support de performance sont-il d'autres avantages de la MVC sur la vue-logique des données en couches motif de type?

EDIT: Pour ceux qui s'intéresse, je vient de mettre une exemple de code PHP que j'ai créé pour tester l'utilisation de MVC. J'omis purposly tous les contrôles de sécurité pour rendre un peu plus facile à lire le code. S'il vous plaît ne critisize pas trop, parce que je sais que ce pourrait être beaucoup plus raffiné et avancé, mais néanmoins - cela fonctionne !!! Je souhaite la bienvenue aux questions et suggestions: Voici le lien: http: / /www.sourcecodester.com/sites/default/files/download/techexpert/test_mvc.zip

Answer 1

La séparation des préoccupations qui est cité comme étant un avantage de MVC est en fait aussi une avance d'un système à 3 couches / 3 niveaux. Là aussi, la logique métier est indépendant et peut être utilisé à partir de différents niveaux de présentation.

Une différence principale est que dans MVC classique, le modèle peut avoir un retour de référence à la vue. Cela signifie que lorsque les données sont mis à jour le modèle peut pousser ce retour de données éventuellement plusieurs vues. L'exemple est une application de bureau où les données sont visualisées de plusieurs façons. Cela peut être aussi simple que d'un tableau et le graphique. Un changement dans la table (qui est un changement dans une vue) est d'abord poussé par l'intermédiaire du dispositif de commande du modèle, ce qui pousse alors le remettre sur le graphe (autre vue). Le graphique puis se met à jour.

Depuis le développement de bureau est sur le déclin, beaucoup de programmeurs ont seulement en contact avec MVC dans une variante web, par exemple via JSF en Java EE.

Dans ces cas, le modèle a presque jamais une référence à la vue. En effet, le web est principalement demande / réponse basée et après une demande a été servi, le serveur ne peut pas envoyer des informations supplémentaires. C'est à dire. une mise à jour du modèle poussé au client serait dénué de sens. Avec ajax / comète inverse cela change, mais beaucoup basé sur le Web frameworks MVC ne sont toujours pas pleinement utiliser cela.

Ainsi, dans le cas du web basé MVC, le « triangle » typique entre M, V et C y est moins et que la variante MVC est en fait plus proche d'un modèle n-tier que « vrai » MVC est.

A noter également que certains cadres MVC Web ont un rôle de plomberie intermédiaire entre M, V et C appelé un haricot de support (Java / JSF) ou un code derrière (ASP.NET). Dans le contrôleur JSF est fourni par le cadre et la vue ne souvent pas se lier directement au modèle, mais utilise ce backing bean d'intermédiaire. La fève de support est très mince et fondamentalement juste pré-fetch données du modèle d'une façon et se traduit par des messages spécifiques au modèle (par exemple, des exceptions) en vue des messages spécifiques (par exemple certains texte lisible par l'homme).

Answer 2

A côté

• réutilisation de code,
• séparation des préoccupations,
• moins couplage entre les couches,

déjà mentionné par @bakoyaro et @ Arjan

Je pense que MVC est meilleur que 3 niveaux lorsqu'il est combiné avec le motif "convention plutôt que configuration" . (À savoir "rubis sur des rails" ou Microsofts "pour MVC asp.net").

A mon avis, ce conduit de combinaison à mieux et code plus facile maintanance .

En premier lieu, il fait l'apprentissage de la mvc-cadre un peu plus difficuilt puisque vous devez apprendre les conventions (un contrôleur La entrent dans les contrôleurs dossier et doit être nommé xxxxxcontroller)

Mais après avoir appris les conventions qu'il est plus facile de maintenir votre propre et le code étranger.

Answer 3

Oublier augmenter la vitesse d'application en se déplaçant à MVC. J'ai trouvé le plus grand avantage d'être facilité de réutilisation de code. Une fois que vous passez à MVC, il n'y a pas de dépendances sur la présentation de vos données ou le stockage des données réelles.

Par exemple vous pouvez écrire un servlet qui servi de pages comme couche de présentation un jour, et le lendemain écrire un service Web comme une autre couche de présentation à votre modèle et contrôleur existant. Comme sage, si vous voulez ou besoin de changer votre SGBD. Depuis l'accès au modèle est complètement séparé de tout le reste, vous juste besoin de re-écriture simplement votre accès aux données des objets pour renvoyer les données d'une manière votre contrôleur peut gérer.

En séparant les préoccupations en 3 parties distinctes, vous facilitez également vrai tests unitaires. Votre couche de présentation peut être testé gratuitement du modèle ou du contrôleur, et vice-versa un.

Sur une note de côté, je me suis souvent senti que l'abréviation MVC était inexacte. Chaque fois que je le vois, je pense comme Affichage-> Controller-> Modèle . La couche de présentation aura jamais le code DAO en elle, et le modèle aura jamais la logique de présentation en elle. Le contrôleur est forcé d'agir en tant qu'intermédiaire entre les deux.

Answer 4

Lorsque la présentation de trois niveaux d'activité et de l'accès aux données, MVC est un motif de couche de présentation qui sépare d'autres modèles (données) de vue (écran) et le contrôleur (entrée).

Il n'y a pas le choix MVC plus de 3 niveaux / 3 couches. Utilisez les deux.