MVC s'applique-t-il uniquement au Web

C'est presque instantané chaque fois que je parle aux développeurs de Model View Controller ( MVC ), ils disent que vous faites une demande à une URL que le serveur crée une entité (MODEL) et vous fournit une représentation visuelle de ce modèle.

• Cela signifie-t-il que MVC est uniquement pour le Web ou ai-je rencontré des gens qui ne sont que des développeurs qui utilisent MVC pour écrire des applications Web?

• Existe-t-il des utilisations pour MVC sur des applications de style bureau?

• Pour ma part, je suis nouveau dans le paradigme et je voudrais connaître tout super-ensemble à MVC

MVC est un modèle. Les modèles s'appliquent à toute la programmation. MVC fonctionne très bien dans un contexte Web.

Comme le souligne gnat, jetez un œil à la balise mvc et vous verrez plusieurs exemples de son implémentation.

Étant donné que MVC date de 1977 et que le Web n'a été inventé qu'en 1991, il devrait être assez évident que MVC n'est pas uniquement destiné au Web.

Non, le développement pour OS X et iOS utilise le modèle Model View Controller.

Posez la question dans un environnement Microsoft et beaucoup de gens penseront que vous voulez dire Asp.Net MVC qui est une implémentation MVC spécifiquement pour le Web.

Malheureusement, beaucoup de gens ne réalisent pas qu'il s'agit d'une implémentation du modèle MVC et pensent que ce sont des termes interchangeables, ce qui conduit à une hypothèse de "Web uniquement".

Pour autant que je sache, la première implémentation de MVC était dans Smalltalk. Il était définitivement présent dans Smalltalk-80. Bien que je n'ai pas de documentation à portée de main pour le prouver, je pense qu'il (ou quelque chose de similaire de toute façon) était dans Smalltalk depuis quelques années.

La plupart des frameworks OO GUI ont inclus au moins une variante de MVC. Je ne suis pas sûr, cependant, exactement ce que "surensemble" signifierait dans ce cas. Il est un peu difficile de dire si une variante donnée est un sur-ensemble, un sous-ensemble ou un pair de MVC, mais j'aurais tendance à considérer la plupart d'entre eux comme des pairs.

Dans tous les cas, beaucoup (la plupart?) D'entre eux ont été utilisés pour le développement de bureau, pas pour le développement Web. Grâce à certains anciens brevets AT&T, la plupart des systèmes de fenêtrage nécessitent des programmes pour pouvoir générer à nouveau des vues à la demande. Cela force (presque) au moins un certain degré de séparation entre le code qui maintient l'état actuel (le modèle) et le code qui affiche cet état (la vue). Cela laisse encore beaucoup de place à la variation dans 1) le degré auquel la fonctionnalité du contrôleur est isolée, et 2) les détails exacts de l'endroit où tracer les lignes entre chacune des pièces principales.

Non, cela s'applique même aux applications autonomes. Exemple Java Swing suit MVC.

Il y a donc beaucoup de modèles de conception différents dans ce domaine.

• Présentateur de vue de modèle (mvp)
• Présentation de la vue du modèle (mvvp)
• Modèle Vue Contrôleur
• Modèle 2

etc. Au fil des ans, ceux-ci ont été entrelacés, mélangés, modifiés et appliqués dans une grande variété de contextes. Le point important ici, c'est que le modèle de conception MVC de 1977 a beaucoup changé et n'est plus le modèle de conception utilisé par les cadres Web côté serveur. À titre d'exemple dans l'implémentation smalltalk d'origine, le modèle observerait la vue des changements, ce qui n'est plus le cas car le côté serveur ne peut tout simplement pas observer les éléments html dans le navigateur des utilisateurs. Au lieu de cela, si la vue change, la vue enverra une demande au contrôleur qui mettra alors à jour la vue. Encore une fois, l'implémentation MVC d'origine n'est pas suivie, car une mise à jour du modèle impliquerait que toutes les vues dépendantes du modèle seraient mises à jour.

Les frameworks web modernes suivent une architecture simple à trois niveaux également connue sous le nom d'architecture Model 2.

Il existe bien sûr des exemples de véritables architectures MVC sur le Web, mais celles-ci sont souvent côté client uniquement, connectées à un serveur qui suit l'architecture Model 2, car les vues sont xml et json, et ne sont pas observées pour les modifications. Des exemples d'architectures mvc pures côté client sont Sencha Touch et Sproutcore.

Si vous avez MVC dans le navigateur, mvc comme sur le serveur et mvc comme couche de données, vous avez une implémentation mvc hiérarchique.

Remarque. Je n'ai parlé que des frameworks Web, d'autres implémentations de MVC telles que java swing et Flex ont d'autres différences d'implémentation.

Une chose que vous devez savoir est qu'il existe autant de versions de MVC que de frameworks qui prétendent implémenter MVC.

La plupart s'accordent sur le fait que le modèle possède un état et que la vue le rend. Mais le contrôleur a des rôles très différents.

Dans Smalltalk, où il a été décrit pour la première fois, le modèle est au cœur de votre application, de vos données et de vos méthodes métier. La vue est une représentation graphique de l'état de l'application (alias modèle) et le contrôleur gère les événements d'entrée utilisateur, de souris et de clavier. Le contrôleur, par exemple, achemine les événements du clavier vers l'élément de vue qui a le focus.

Dans les pages .jsp, le modèle est principalement composé de données, la vue rend ce modèle au format HTML et le contrôleur effectue le routage du modèle vers la vue appropriée pour le rendre.

Donc, pour répondre à votre question, bien que MVC soit utilisé à la fois sur des applications autonomes (Java, .Net, Flex) et sur le Web (pages jsp), c'est une chose très différente. Cela signifie que le MVC que vous connaissez n'est pas utilisé dans les applications autonomes.