Quelles sont les forces et les faiblesses de la de nombreux cadres basé sur backbone.js?

La plupart (tous?) les cadres que vous êtes à la recherche à résoudre les mêmes problèmes, mais ils le font de façons légèrement différentes légèrement différents objectifs.

Je pense qu'il est juste de dire que tous ces projets permettrait de résoudre les problèmes de ces catégories:

• Fournir judicieux de définir des valeurs par défaut
• Réduire code réutilisable
• Fournir la structure de l'application sur le dessus de la BackboneJS blocs de construction
• Extraire des motifs que les auteurs utilisent dans leurs applications

De marionnettes, dont j'ai été la construction depuis décembre 2011, a quelques très distinctes les objectifs et les idéaux de l'esprit, ainsi:

• Composite de l'architecture de l'application
• De messagerie d'entreprise modèle de l'influence
• La modularisation des options
• Différentiels utilisation (pas tout-ou-rien exigence)
• Pas de serveur de verrouillage
• Faire, il est facile de changer ces valeurs par défaut
• Code de configuration de /au-dessus de configuration

Je ne dis pas qu'aucun des autres cadres de ces mêmes objectifs. Mais je pense que la Marionnette de l'originalité vient de la combinaison de ces objectifs.

Composite De L'Architecture De L'Application

J'ai passé plus de 5 ans de travail en client lourd, distribuée systèmes de logiciels à l'aide de WinForms et C#. J'ai construit des applications pour ordinateur de bureau, ordinateur portable (smart-client), les appareils mobiles et les applications web, partageant tous un noyau fonctionnel et de travail avec le même serveur back-end de nombreuses fois. En ce moment, j'ai appris la valeur de la modularisation et très rapidement déplacé vers le bas un chemin de composite de la conception de l'application.

L'idée de base est de "composer" de votre application d'exécution de l'expérience et le processus de beaucoup de petites pièces qui ne savent pas forcément les uns des autres. Ils s'inscrivent eux-mêmes avec l'ensemble de l'application composite système, puis ils communiquent par le biais de divers moyens de découplée des messages et des appels.

J'ai écrit un peu à ce sujet sur mon blog, l'introduction de la Marionnette comme un composite de l'architecture de l'application pour la colonne vertébrale:

• http://lostechies.com/derickbailey/2011/11/17/introduction-to-composite-javascript-apps/
• http://lostechies.com/derickbailey/2011/12/12/composite-js-apps-regions-and-region-managers/

Files D'Attente De Messages /Motifs

Même à grande échelle, les systèmes distribués également profité de message queuing, enterprise integration patterns (modèles de messagerie), et le service de bus pour gérer les messages. Cela, plus que tout autre, a eu une influence énorme sur mon approche découplée de développement de logiciels. J'ai commencé à voir un processus unique, en mémoire des applications WinForms de ce point de vue, et bientôt mon côté serveur et développement de l'application web a pris de l'influence de cette.

Cela s'est directement traduit lui-même à la façon dont je regarde épine Dorsale de la conception de l'application. - Je fournir un agrégateur d'événements dans la Marionnette, pour à la fois le haut niveau de l'objet Application, et pour chaque module que vous créez dans l'application.

Je pense que sur les messages que je peux envoyer entre mes modules: les messages de commande, les messages d'événements, et plus encore. Je pense aussi que sur le côté serveur de communication comme des messages avec ces mêmes modèles. Certains modèles ont fait leur chemin dans la Marionnette déjà, mais certains n'ont pas encore.

• http://lostechies.com/derickbailey/2011/07/19/references-routing-and-the-event-aggregator-coordinating-views-in-backbone-js/
• http://lostechies.com/derickbailey/2012/04/03/revisiting-the-backbone-event-aggregator-lessons-learned/
• http://lostechies.com/derickbailey/2009/12/23/understanding-the-application-controller-through-object-messaging-patterns/ (WinForms code, mais encore applicable)

La modularisation

La modularisation du code est extrêmement important. La création de petites encapsulé les paquets qui ont un accent singulier avec bien défini d'entrée et de sortie est un must pour n'importe quel système d'une certaine taille et de la complexité.

Marionnette fournit la modularisation directement par le biais de module définitions. Mais je reconnais aussi que certaines personnes aiment RequireJS et souhaitez l'utiliser. J'ai donc fournir à la fois une version standard et une RequireJS compatible construire.

MyApp = new Backbone.Marionette.Application();

MyApp.module("MyModule", function(MyModule, MyApp, Backbone, Marionette, $, _){

  //your module code goes here

});

(Pas de blog disponibles pour cela, encore)

Différentiels Utilisation

C'est l'une des philosophies de base que j'ai faites cuire dans chaque partie de la Marionnette que je peux: pas de "tout ou rien" pour l'utilisation de la Marionnette.

Épine dorsale prend elle-même un très progressive et modulaire approche avec l'ensemble de bloc de construction des objets. Vous êtes libre de choisir ceux que vous souhaitez utiliser, quand. Je crois fermement à ce principe et efforcera de faire en sorte de Marionnette fonctionne de la même manière.

À cette fin, la majorité des pièces que j'ai intégré à de Marionnettes sont construits pour résister à lui seul, à travailler avec les principaux morceaux de la colonne vertébrale, et à travailler ensemble, même mieux.

Par exemple, presque chaque épine Dorsale de l'application doit afficher dynamiquement un Squelette à afficher dans un certain endroit sur l'écran. Les applications doivent aussi gérer la fermeture de vues anciennes et de nettoyage de la mémoire quand un nouveau est mis en place. C'est là que la Marionnette de Region vient de jouer. Une région gère le code standard de la prise de vue, l'appel de rendu, et la farce de la suite dans les DOM pour vous. Alors ferme la vue et de la nettoyer pour vous, à condition que votre point de vue a un "proche" de la méthode.

MyApp.addRegions({
  someRegion: "#some-div"
});

MyApp.someRegion.show(new MyView());

Mais vous n'êtes pas obligé d'utiliser des Marionnettes du point de vue afin d'utiliser une région. La seule exigence est que vous êtes s'étendant à partir de la colonne vertébrale.Vue à un certain point du prototype de l'objet de la chaîne. Si vous choisissez de fournir un close méthode, un onShow méthode, ou d'autres, de la Marionnette de la Région vous appeler au bon moment.

• http://lostechies.com/derickbailey/2011/12/12/composite-js-apps-regions-and-region-managers/
• http://lostechies.com/derickbailey/2011/09/15/zombies-run-managing-page-transitions-in-backbone-apps/

Pas de Serveur de Verrouillage

- Je construire Backbone /Marionnette applications sur une grande variété de technologies de serveur:

• ASP.NET MVC
• Ruby on Rails
• Ruby /Sinatra
• NodeJS /ExpressJS
• PHP /Slim
• Java
• Erlang
• ... et plus

JavaScript JavaScript est-il, quand il s'agit de s'exécutant dans un navigateur. Côté serveur JavaScript est génial aussi, mais il n'a aucun effet ou une influence sur la façon dont j'écris mon navigateur basé sur le JavaScript.

En raison de la diversité des projets que j'ai construit et les technologies de mes clients, je ne peux pas et ne sera pas de verrouillage de la Marionnette dans un seul serveur côté pile de la technologie pour une raison quelconque. Je ne vais pas mettre un passe-partout de projet. Je ne vais pas mettre un rubis gemme ou d'un mécanisme de prévention de package. Je veux que les gens comprennent que la Marionnette n'a pas besoin d'un serveur de back-end. Il est basé sur un navigateur JavaScript, et le back-end n'a pas d'importance.

Bien sûr, je suis entièrement d'appuyer d'autres personnes fournissant des paquets pour leur langue et leur cadre. Je liste les paquets dans le Wiki, et j'espère que les gens de continuer à construire plus de paquets qu'ils voient un besoin. Mais qui est le soutien de la communauté, pas de soutien direct de la Marionnette.

• https://github.com/derickbailey/backbone.marionette/wiki/Available-packages

Facilement Modifier Les Valeurs Par Défaut

Dans mes efforts pour réduire code réutilisable et de fournir des valeurs par défaut raisonnables (ce qui est une idée que j'ai directement "emprunté" de Tim Branyen de LayoutManager), je reconnais la nécessité pour les autres développeurs à utiliser légèrement différentes implémentations que je fais.

Je fournir rendu en fonction inline <script> balises pour les modèles, à l'aide de Underscore.js les templates par défaut. Mais vous pouvez le remplacer par la modification de la Renderer et/ou TempalteCache objets en de Marionnettes. Ces deux objets fournissent la base des capacités de rendu, et il y a des pages wiki qui montrent comment modifier ce pour différents gabarits pour les moteurs et les différentes façons de chargement de modèles.

Avec v0.9 de la Marionnette, il devient encore plus facile. Par exemple, si vous souhaitez remplacer l'utilisation de inline modèle des blocs de script avec pré-compilé de modèles, vous n'avez qu'à remplacer une méthode sur le moteur de Rendu:

Backbone.Marionette.Renderer.render = function(template, data){
  return template(data);
};

et maintenant, l'application de l'utilisation de pré-compilé les modèles que vous joignez à votre vue template attribut.

J'ai même fournir une Marionnette.Async add-on avec v0.9 qui vous permet de soutenir de manière asynchrone rendre la vue. Je continue de s'efforcer de le rendre aussi facile que possible de remplacer le comportement par défaut de la Marionnette.

Code De Configuration

Je suis un fan de "convention over configuration" dans certains contextes. C'est un moyen puissant de faire les choses, et de Marionnettes fournit un petit peu - mais pas trop, honnêtement. De nombreux autres cadres - surtout LayoutManager - davantage de convention over configuration que la Marionnette n'.

C'est fait avec un but et une intention.

J'ai construit assez de plugins JavaScript, des cadres, des add-ons et des applications à connaître la douleur d'essayer d'obtenir des conventions de travailler sérieusement et rapidement. Il peut être fait avec de la vitesse, mais généralement au détriment d'être en mesure de le changer.

À cette fin, je prends un "code de configuration" dans l'approche de la Marionnette. Je n'ai pas fournir beaucoup de "configuration" Api où vous pouvez fournir un littéral d'objet avec des valeurs statiques qui changent une bande de comportements. Au lieu de cela, j'ai documenter les méthodes que chaque objet a, par l'intermédiaire du annotée du code source et de la réelle documentation de l'API - avec l'intention de vous dire comment changer de Marionnette à travailler comme vous le souhaitez.

En fournissant un environnement propre et claire de l'API pour la Marionnette des objets, j'ai créer une situation où, en remplaçant le comportement d'un objet spécifique ou la Marionnette dans son ensemble est relativement simple et très flexible. Je le sacrifice de la "simple" configuration des appels de l'API pour la flexibilité de fournir votre propre code pour faire fonctionner les choses de la manière que vous voulez.

Vous ne trouverez pas un "configurer" ou "options" de l'API dans la Marionnette. Mais vous trouverez un grand nombre de méthodes qui servent chacun un but très précis, propres signatures, qui font qu'il est facile de changer la façon de Marionnettes œuvres.

J'ai étudié les différents cadres de construire avec Backbone.js et construit les Vertèbres pour un projet à HauteLook. Les objectifs du projet sont inclus... dynamique script de chargement, AMD module de format, de gestion de la dépendance, de construire avec la plupart des bibliothèques open source, organiser le code en paquets, d'optimiser et de construire pour une ou plusieurs single page apps, hôte sur la pleine mise en cache du serveur, par exemple, pas de script côté serveur en utilisant seulement une API pour les données, et le plus amusant, pour moi, l'utilisation de comportement conduit au développement du projet. Il y a une description du projet : http://www.hautelooktech.com/2012/05/24/vertebrae-front-end-framework-built-with-backbone-js-and-requirejs-using-amd/

Notre Problème:

Sélectionné librairies (jQuery, Underscore.js, Backbone.js, RequireJS, Moustache) fournir le module de chargement, de la gestion de la dépendance, de la structure des applications (pour les modèles, des collections, des vues et des routes), asynchrone interactions avec les API, les différents services publics et des objets pour gérer les comportements asynchrones, par exemple (Promesses) Deferreds, les Callbacks. Le reste logique nécessaire pour compléter le cadre comprend:

• un objet (model) pour la gestion de l'état de la seule page de l'application;
• un gestionnaire de présentation pour présenter, organiser/transition et d'effacer les vues, et
• contrôleurs qui répondent aux itinéraires, obtenir/définir l'état de l'application, et de la main d'un arrêt de travail à la disposition du gestionnaire.

Nos Solutions (mis en œuvre dans les Vertèbres):

L'État De L'Application Gestionnaire De -

Le gestionnaire de l'application stocke les données en mémoire et persiste également des données dans le navigateur de stockage pour fournir une ressource pour la commune de données/métadonnées. Fournit également des données (état) afin de reconstruire la page des vues basées sur les interactions (par exemple, l'onglet sélectionné, les filtres appliqués). L'état de l'application manager fournit une stratégie pour les ressources à récupérer de l'etat. Conçu pour agir comme une machine à état.

Layout Manager -

Le layout manager dispose d'un ou de plusieurs points de vue ainsi que le document (DOM) les destinations pour chaque (rendu) de la vue. Une page de transition entre le nombre de vues, de sorte que le gestionnaire de mise en page permet de suivre des états d'affichage, par exemple, rendu, pas-rendus, affiche, pas affichées. Vous pouvez utiliser le gestionnaire de présentation charge paresseux et render (détaché) qu'un visiteur du site est très probablement à la demande, par exemple, l'onglet modifications sur une page. La transition entre les états d'affichage est gérée par cet objet. Toute une mise en page peut être désactivée afin que la vue des objets et de leurs liaisons sont supprimés, la préparation de ces objets pour la collecte des déchets (prévention des fuites de mémoire). Le layout manager communique aussi de l'état d'affichage avec le contrôleur(s).

Contrôleur -

Un objet contrôleur est appelé par un itinéraire en fonction de gestionnaire, et est responsable de l'obtention de l'état concernés (modèles d'application) pour générer une page (layout), (également responsable de la mise en état lors de la modification de parcours). Le contrôleur transmet les données dépendantes (modèles/collections) et construit de visualiser les objets pour une demande de page à la disposition du gestionnaire. Comme un effet secondaire de l'utilisation de contrôleurs empêche les routes de l'objet de devenir pléthorique et emmêlés. Un itinéraire doit correspondre à un contrôleur qui intervient puis désactiver l'affichage de la page, en gardant la route des fonctions de gestion lean.

Todos application est hébergée à la fois en dev mode et optimisé sur Heroku...

• http://vertebrae-framework.herokuapp.com/
• http://vertebrae-optimized.herokuapp.com/

De nombreux concepts dans les autres cadres sont empruntés, par exemple la nécessité de destory vues pour afficher l'aperçu des fuites de mémoire, comme l'a souligné Derick Bailey - http://lostechies.com/derickbailey/ ; le Layout Manager par Tim Branyen http://tbranyen.github.com/backbone.layoutmanager/

En résumé, Backbone.js est destiné à être un outil dans votre demande Backbone.js la bibliothèque ne fournissent pas toute l'architecture, vous aurez besoin de construire une application, mais ne fournissent de grandes interactions avec une API et une solide structure de code pour... Vues (loi comme les contrôleurs trop) et votre couche de données des Modèles et des Collections, et enfin les Routes. Nous avons construit des Vertèbres de la viande que les objectifs de notre projet, et a décidé d'extraire le code comme un cadre à utiliser pour les autres, d'apprendre, ou de quoi que ce soit.

La réponse à votre question, à mon avis, est d'apprendre de tous les cadres et utiliser ce que vous avez besoin pour atteindre vos objectifs, si vous trouvez que votre projet objectifs ajustement en étroite collaboration avec l'un des cadres construits avec l'épine Dorsale, puis une grande, sinon à construire votre propre cadre il y a de grands exemples partagé par la communauté. Ou si vous trouvez vous-même un peu perdu dans la direction de votre application, puis choisissez quelque chose de plus opiniâtre et structurée peut-être Ember.js. La grande chose est, il ya une bonne gamme de choix pour vous aider à code à l'aide d'un (MVX) comme le modèle MVC avec JavaScript.

Je suis un co-auteur de Chaplin et j'ai écrit une comparaison approfondie entre les Chaplin.js et Marionette.js:

http://9elements.com/io/index.php/comparison-of-marionette-and-chaplin/

Ce n'est pas un “échange de tirs”, mais tente d'expliquer les deux approches de façon équilibrée.