La plupart (tous?) Des frameworks que vous envisagez résolvent les mêmes problèmes, mais ils le font de manière légèrement différente avec des objectifs légèrement différents.
Je pense qu'il est juste de dire que tous ces projets résoudraient les problèmes dans ces catégories:
- Fournir un ensemble judicieux de valeurs par défaut
- Réduire le code passe-partout
- Fournir une structure d'application au-dessus des blocs de construction BackboneJS
- Extraire les modèles que les auteurs utilisent dans leurs applications
Marionette, que je construis depuis décembre 2011, a également en tête quelques objectifs et idéaux bien distincts:
- Architecture d'application composite
- Influence du modèle de messagerie d'entreprise
- Options de modularisation
- Utilisation incrémentale (pas d'exigence de tout ou rien)
- Pas de verrouillage du serveur
- Facilitez la modification de ces valeurs par défaut
- Code comme configuration / sur configuration
Je ne dis pas qu'aucun des autres cadres n'a les mêmes objectifs. Mais je pense que le caractère unique de Marionette vient de la combinaison de ces objectifs.
Architecture d'application composite
J'ai passé plus de 5 ans à travailler dans des systèmes logiciels distribués de clients lourds utilisant WinForms et C #. J'ai créé des applications pour les ordinateurs de bureau, les ordinateurs portables (client intelligent), les appareils mobiles et les applications Web, partageant tous un ensemble fonctionnel de base et travaillant plusieurs fois avec le même serveur principal. À cette époque, j'ai appris la valeur de la modularisation et j'ai très rapidement emprunté la voie de la conception d'applications composites.
L'idée de base est de «composer» l'expérience d'exécution de votre application et de la traiter à partir de nombreuses pièces individuelles plus petites qui ne se connaissent pas nécessairement. Ils s'enregistrent auprès du système d'application composite global, puis ils communiquent par divers moyens de messages et d'appels découplés.
J'ai écrit un peu à ce sujet sur mon blog, présentant Marionette en tant qu'architecture d'application composite pour Backbone:
Files d'attente / modèles de messages
Les mêmes systèmes distribués à grande échelle ont également tiré parti de la mise en file d'attente des messages, des modèles d'intégration d'entreprise (modèles de messagerie) et des bus de services pour gérer les messages. Ceci, plus que toute autre chose, a eu une influence considérable sur mon approche du développement logiciel découplé. J'ai commencé à voir des applications WinForms en mémoire à un seul processus de ce point de vue, et bientôt mon côté serveur et le développement d'applications Web en ont pris une influence.
Cela s'est directement traduit par la façon dont je regarde la conception des applications Backbone. Je propose un agrégateur d'événements dans Marionette, à la fois pour l'objet Application de haut niveau et pour chaque module que vous créez dans l'application.
Je pense aux messages que je peux envoyer entre mes modules: messages de commande, messages d'événement, etc. Je pense également à la communication côté serveur comme des messages avec ces mêmes modèles. Certains des modèles ont déjà fait leur chemin dans Marionette, mais certains ne l'ont pas encore fait.
La modularisation
La modularisation du code est extrêmement importante. La création de petits paquets bien encapsulés qui ont un objectif unique avec des points d'entrée et de sortie bien définis est un must pour tout système de toute taille et complexité importantes.
Marionette fournit la modularisation directement à travers ses moduledéfinitions. Mais je reconnais aussi que certaines personnes aiment RequireJS et veulent l'utiliser. Je propose donc à la fois une version standard et une version compatible RequireJS.
MyApp = new Backbone.Marionette.Application();
MyApp.module("MyModule", function(MyModule, MyApp, Backbone, Marionette, $, _){
// your module code goes here
});
(Aucun article de blog disponible pour le moment)
Utilisation incrémentale
C'est l'une des philosophies de base que j'introduis dans chaque partie de Marionette que je peux: pas d'exigence "tout ou rien" pour l'utilisation de Marionette.
Backbone lui-même adopte une approche très incrémentale et modulaire avec tous ses objets de base. Vous êtes libre de choisir ceux que vous souhaitez utiliser, quand. Je crois fermement en ce principe et je m'efforce de m'assurer que Marionette fonctionne de la même manière.
À cette fin, la majorité des pièces que j'ai intégrées à Marionette sont conçues pour être autonomes, pour travailler avec les pièces maîtresses de Backbone et pour mieux travailler ensemble.
Par exemple, presque toutes les applications Backbone doivent afficher dynamiquement une vue Backbone à un endroit particulier de l'écran. Les applications doivent également gérer la fermeture des anciennes vues et le nettoyage de la mémoire lorsqu'une nouvelle est mise en place. C'est là qu'intervient Marionette Regionpour jouer. Une région gère le code standard de la prise de vue, de l'appel de rendu et du remplissage du résultat dans le DOM pour vous. Puis fermera cette vue et la nettoiera pour vous, à condition que votre vue comporte une méthode de "fermeture".
MyApp.addRegions({
someRegion: "#some-div"
});
MyApp.someRegion.show(new MyView());
Mais vous n'êtes pas obligé d'utiliser les vues de Marionette pour utiliser une région. La seule exigence est que vous étendez à partir de Backbone.View à un moment donné dans la chaîne de prototypes de l'objet. Si vous choisissez de fournir une closeméthode, une onShowméthode ou d'autres, Marionette's Region l'appellera pour vous au bon moment.
Pas de verrouillage du serveur
Je construis des applications Backbone / Marionette sur une grande variété de technologies de serveur:
- ASP.NET MVC
- Rubis sur rails
- Rubis / Sinatra
- NodeJS / ExpressJS
- PHP / Slim
- Java
- Erlang
- ... et plus
JavaScript est JavaScript, lorsqu'il s'agit de s'exécuter dans un navigateur. Le JavaScript côté serveur est également génial, mais il n'a aucun effet ni aucune influence sur la façon dont j'écris le JavaScript basé sur mon navigateur.
En raison de la diversité des projets que j'ai construits et des technologies dorsales que mes clients utilisent, je ne peux pas et ne veux pas verrouiller Marionette dans une seule pile technologique côté serveur pour quelque raison que ce soit. Je ne fournirai pas de projet standard. Je ne fournirai pas de gemme rubis ou de package npm. Je veux que les gens comprennent que Marionette ne nécessite pas de serveur back-end spécifique. C'est du JavaScript basé sur un navigateur, et le back-end n'a pas d'importance.
Bien sûr, je soutiens pleinement d'autres personnes en fournissant des packages pour leur langage et leur framework. J'énumère ces paquets dans le Wiki et j'espère que les gens continueront à construire plus de paquets lorsqu'ils en voient un besoin. Mais c'est un soutien communautaire, pas un soutien direct de Marionette.
Modifiez facilement les valeurs par défaut
Dans mes efforts pour réduire le code standard et fournir des valeurs par défaut raisonnables (ce qui est une idée que j'ai directement «empruntée» au LayoutManager de Tim Branyen), je reconnais la nécessité pour d'autres développeurs d'utiliser des implémentations légèrement différentes de celles que je fais.
Je propose un rendu basé sur des <script>balises en ligne pour les modèles, en utilisant le modèle Underscore.js par défaut. Mais vous pouvez le remplacer en modifiant les objets Rendereret / ou TempalteCachedans Marionette. Ces deux objets fournissent le cœur des capacités de rendu, et il existe des pages wiki qui montrent comment changer cela pour des moteurs de modèles spécifiques et différentes façons de charger des modèles.
Avec la v0.9 de Marionette, cela devient encore plus facile. Par exemple, si vous souhaitez remplacer l'utilisation de blocs de script de modèle en ligne par des modèles précompilés, 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 entière utilisera des modèles pré-compilés que vous attachez à l' templateattribut de votre vue .
Je propose même un add-on Marionette.Async avec la v0.9 qui vous permet de prendre en charge le rendu de vues de manière asynchrone. Je m'efforce continuellement de rendre le plus simple possible le remplacement des comportements par défaut dans Marionette.
Code comme configuration
Je suis fan de "convention sur configuration" dans certains contextes. C'est un moyen puissant de faire avancer les choses, et Marionette en fournit un peu - mais pas trop, honnêtement. De nombreux autres frameworks - en particulier LayoutManager - fournissent plus de convention sur la configuration que Marionette.
Ceci est fait avec un but et une intention.
J'ai construit suffisamment de plugins, de frameworks, de modules complémentaires et d'applications JavaScript pour connaître la douleur d'essayer de faire fonctionner les conventions de manière significative et rapide. Cela peut être fait avec rapidité, mais généralement au prix de pouvoir le changer.
Pour cela, j'adopte une approche "code as configuration" de Marionette. Je ne fournis pas beaucoup d'API de «configuration» où vous pouvez fournir un objet littéral avec des valeurs statiques qui changent un éventail de comportements. Au lieu de cela, je documente les méthodes de chaque objet - à la fois via le code source annoté et via la documentation de l'API réelle - dans le but de vous dire comment modifier Marionette pour qu'elle fonctionne comme vous le souhaitez.
En fournissant une API propre et claire pour les objets Marionette, je crée une situation où le remplacement du comportement d'un objet spécifique ou de la Marionette dans son ensemble est relativement simple et très flexible. Je sacrifie les appels de l'API de configuration «simple» à la flexibilité de fournir votre propre code pour que les choses fonctionnent comme vous le souhaitez.
Vous ne trouverez pas d'API "configure" ou "options" dans Marionette. Mais vous trouverez un grand nombre de méthodes qui servent chacune un but très spécifique, avec des signatures propres, qui facilitent le changement du fonctionnement de Marionette.
