Alors que le développement front-end est de plus en plus valorisé et que la proportion de code client augmente de jour en jour, la question de savoir comment appliquer le modèle MVC dans le développement JavaScript semble être mentionnée tout le temps, j'aimerais donc en parler brièvement à propos de mes opinions ici.
L'idée de base du modèle MVC est de réduire le couplage et de simplifier le développement en encapsulant une application en trois parties : modèle, vue et contrôleur. C’est creux de dire ça. Prenons un exemple :
<select id="selAnimal"> <option value="cat">cat</option> <option value="fish">fish</option> <option value="bird">bird</option> </select> <p id="whatDoesThisAnimalDo"></p> <script type="text/javascript"> document.getElementById('selAnimal').onchange = function() { var thisAnimalDoes; switch ( this.value ) { case 'cat': thisAnimalDoes = "cat meows"; break; case 'fish': thisAnimalDoes = "fish swims"; break; case 'bird': thisAnimalDoes = "bird flies"; break; default: thisAnimalDoes = "wuff?"; } document.getElementById('whatDoesThisAnimalDo').innerHTML = thisAnimalDoes; } </script>
Ce petit programme fera écho à ce que l'animal que vous sélectionnez dans le menu déroulant "selAnimal" peut faire sur la page Web. Ce qui précède est du code écrit sans appliquer de modèles de conception ou d’idées de programmation. Si nous voulons appliquer le modèle MVC ici, à quoi ressemblera le code ?
<select id="selAnimal"> <option value="cat">cat</option> <option value="fish">fish</option> <option value="bird">bird</option> </select> <p id="whatDoesThisAnimalDo"></p> <script type="text/javascript"> // whatDoesAnimalDo 就是一个controller var whatDoesAnimalDo = { // 选择视图 start: function() { this.view.start(); }, // 将用户的操作映射到模型的更新上 set: function(animalName) { this.model.setAnimal(animalName); }, }; // whatDoesAnimalDo的数据model whatDoesAnimalDo.model = { // animal的数据 animalDictionary: { cat: "meows", fish: "swims", bird: "flies" }, // 当前的animal,也就是这个application的状态 currentAnimal: null, // 数据模型负责业务逻辑和数据存储 setAnimal: function(animalName) { this.currentAnimal = this.animalDictionary[animalName] ? animalName : null; this.onchange(); }, // 并且通知视图更新显示 onchange: function() { whatDoesAnimalDo.view.update(); }, // 还需要响应视图对当前状态的查询 getAnimalAction: function() { return this.currentAnimal ? this.currentAnimal + " " + this.animalDictionary[this.currentAnimal] : "wuff?"; } }; // whatDoesAnimalDo的视图 whatDoesAnimalDo.view = { // 用户输入触发onchange事件 start: function() { document.getElementById('selAnimal').onchange = this.onchange; }, // 该事件将用户请求发送给控制器 onchange: function() { whatDoesAnimalDo.set(document.getElementById('selAnimal').value); }, // 视图更新显示的方法,其中视图会向model查询当前的状态,并将其显示给用户 update: function() { document.getElementById('whatDoesThisAnimalDo').innerHTML = whatDoesAnimalDo.model.getAnimalAction(); } }; whatDoesAnimalDo.start(); </script>
...Tout à coup, le code est devenu tellement exagéré....
——Odu n'y a pas encore implémenté le mode observateur...
Ce n'est vraiment pas bon.
Cela fait ressortir la plus grande critique du modèle MVC : l'application du modèle MVC dans un système simple augmentera la complexité de la structure et réduira l'efficacité.
Je pense donc qu'à l'exception de quelques contrôles javascript, tels que le contrôle de grille de données/arborescence permettant de cliquer n'importe où pour modifier, ou les éditeurs de texte enrichi comme FckEditor/tinyMCE qui prennent en charge les plugins personnalisés, qui sont très adaptés à l'application de MVC, dans La plupart Dans un système B/S pratique, tant que vous suivez le modèle d'usine dans le développement JavaScript, vous en bénéficierez beaucoup. Cela est dû à la nature différente du développement front-end et du développement back-end. Si vous appliquez le modèle MVC dans un projet ASP.net ou JSP, le SDK générera plus ou moins automatiquement du code de vue et de contrôleur. Mais qu'en est-il de JavaScript : JavaScript n'a même pas de SDK utile. Bien qu'il existe de nombreux frameworks matures, cela augmentera considérablement la quantité de développement.
Par rapport à la quantité de développement, ce qui est plus problématique est la question de l'efficacité. L'intercommunication entre les trois couches représente une surcharge supplémentaire. Côté serveur, la surcharge provoquée par ces communications est presque négligeable. Mais pour un langage relativement inefficace comme javascript, quelques appels supplémentaires et l'écoute d'événements réduiront évidemment les performances. De plus, en raison de la fonction de fermeture de javascript, des fuites de mémoire peuvent se produire accidentellement. Il s'agit d'un cas authentique de vol de poulet mais de perte de riz...
.
Par conséquent, pour le développement JavaScript, un développement modéré peut être plus important que l'application des connaissances académiques que vous avez acquises. Après tout, le développement front-end est basé sur la résolution de problèmes pratiques et non sur la démonstration de compétences. Bien sûr, Dflying gg a un dicton selon lequel "la refactorisation est partout" - si vous sentez que votre propre code devient de plus en plus compliqué et plus difficile à maintenir, alors vous devriez vous demander si vous devez utiliser MVC pour le refactoriser ~
Encore une chose : l'ensemble du développement front-end n'a-t-il plus besoin d'utiliser MVC ? non non~ En fait, tout le développement front-end est une grande architecture MVC——
Modèle : Informations en HTML/XHTML
Vue : Feuille de style
Contrôleur : EMAScripts et autres scripts
N'est-ce pas le but ultime des standards du web....
Par conséquent, il est toujours plus important de comprendre la structure de l'ensemble du code front-end que de sur-appliquer des modèles de conception dans le développement JavaScript !
Cependant, il existe également d'excellents frameworks MVC. Gordon L. Hempton, hacker et concepteur à Seattle, a fait une comparaison ici pour y jeter un œil :
1. Backbone.js - Avantages : communauté forte, forte dynamique Inconvénients : abstraction faible, de nombreuses fonctions doivent être ajoutées de toute urgence ;
2. SproutCore - Avantages : prise en charge de la liaison, communauté fiable, grand nombre de fonctionnalités Inconvénients : surspécification, difficile à dissocier des fonctionnalités inutiles ;
3. Sammy.js - Avantages : facile à apprendre et plus facile à intégrer aux applications serveur existantes Inconvénients : trop simple pour être utilisé dans de grandes applications ;
4. Spine.js - Avantages : documentation légère et complète ; Inconvénients : Son concept de base « spine » est une interface utilisateur asynchrone, ce qui signifie qu'idéalement l'interface utilisateur ne sera jamais bloquée, et cette fondation est imparfaite. .
5. Cappuccino - Avantages : Grand framework bien pensé, bonne communauté, excellent modèle d'héritage ; Inconvénients : Créé par des développeurs iOS, utilisant JavaScript pour simuler Objective-C ;
6. Knockout.js - Avantages : Prise en charge de la liaison, documentation complète et tutoriels Inconvénients : Mauvaise syntaxe de liaison, manque de hiérarchie de composants de vue unifiée ;
7. Javascript MVC - Avantages : communauté fiable ; Inconvénients : mauvais modèle d'héritage basé sur les chaînes, relation trop étroite entre le contrôleur et la vue et manque de liaison.
8. GWT (Google Web Toolkit) - Avantages : framework complet, bonne communauté, modèle d'héritage de composants fiable basé sur Java Inconvénients : peut ne pas résister à l'épreuve du temps, de plus, Java est côté client ; L'abstraction ci-dessus est un peu maladroite.
9. Google Closure——Avantages : Très bon système de composition d'interface utilisateur basé sur des composants. Inconvénients : manque de prise en charge des liaisons d'interface utilisateur.
10. Ember.js - Avantages : Système de modèles très riche, avec des vues composites et une liaison d'interface utilisateur Inconvénients : Il est relativement nouveau et la documentation n'est pas assez complète ;
11. Angular.js - Avantages : il prend en compte la portée du modèle et la conception du contrôleur, dispose d'un système d'injection de dépendances et prend en charge une syntaxe de liaison d'interface utilisateur riche. Inconvénients : La modularité du code n'est pas forte, et la modularité de la vue n'est pas suffisante.
12. Batman.js——Avantages : code clair, méthodes de liaison et de persistance simples. Inconvénients : un contrôleur singleton est utilisé.