mvc - Comment gérer la relation entre la vue modèle et d'autres éléments dans les applications graphiques non Web?

Question

Aujourd'hui, je me suis plaint et j'ai posté un Weibo :
http://weibo.com/1651843872/B09Wxlokv?mod=weibotime

Avec le recul, l'interface de jQuery peut même être nuisible aux grandes applications. Le concept de MVC fait largement abstraction d'un modèle clair, et la vue est synchronisée avec l'interface basée sur le modèle. Dans jQuery, la vue est directement exploitée comme un modèle. Modèle.. J'étais confus jusqu'au bout.

J'ai appris le front-end parce que j'ai réalisé que développer des interfaces graphiques sur la plateforme Web est très bon marché,
Ce n'est que lorsque j'ai commencé à travailler sur des applications que j'ai commencé à vraiment réaliser la complexité des applications graphiques..
Si je me souviens bien, ce processus d'apprentissage était simplement une lutte étape par étape contre l'utilisation de jQuery..
La séparation du modèle, de la vue et des autres composants et de leurs parties respectives ne peut que progressivement devenir plus réaliste.

Le Web est très compliqué, car le DOM a déjà une couche d'abstraction, et il bloque également certaines routes en termes de fourniture,
Alors, comment gérer la relation entre View et Model dans le développement graphique sur d'autres plateformes sans DOM ?

Par exemple, l'implémentation sous-jacente de la bibliothèque d'outils Webkit conserve Model et View.
Il existe également Unity3D, Flash, etc. Comment comprenez-vous ces parties ?

La question est un peu générale. Merci de me donner quelques conseils, merci.

Answer 1

Attends une minute, pourquoi es-tu contre jQ ? jQ est une encapsulation d'opération DOM et n'a presque rien à voir avec MVC. Tout comme se battre avec des fusils et des canons, on ne peut pas dire "Je me rends compte qu'un canon peut faire exploser un bunker d'un seul coup, donc l'utilisation de fusils est nuisible au champ de bataille"

En fait, bien qu'AngularJS ne préconise pas de jq, l'essence est de rationaliser l'utilisation de jqLite, tandis que Backbone est naturellement pro-jQ. Les grandes applications n'ont aucune structure. Le codage en dur dans jQ est certainement une mauvaise façon de procéder, mais penser simplement qu'implémenter MVC sans jQ n'est pas une bonne idée.

Je publie ma critique du Backbone de l’année dernière pour référence. En fait, je pense maintenant qu'à moins qu'il ne s'agisse d'une application de type "interface de gestion", mécanisme Backbone ou Backbone-like Model, spécifiquement Backbone.sync用处不大。因为浏览器端的JS天生不『拥有』任何数据，不会负责数据的简单CURD式的落地（H5涉及离线本地存储另说）。浏览器端JS可能更需要的是维护数据和DOM绑定，也就是所谓ViewModel, référez-vous à KnockoutJS

Désolé de ne pas avoir d'expérience hors Web.