backbone.js alternative example - Was sind die wirklichen Stärken und Schwächen der vielen Frameworks, die auf backbone.js basieren?




3 Answers

Die meisten (alle von?) Frameworks, die Sie betrachten, lösen die gleichen Probleme, aber sie tun es auf leicht unterschiedliche Weise mit etwas anderen Zielen.

Ich denke, es ist fair zu sagen, dass alle diese Projekte die Probleme in diesen Kategorien lösen würden:

  • Stellen Sie sinnvolle Standardeinstellungen bereit
  • Reduzieren Sie den Standardcode
  • Stellen Sie eine Anwendungsstruktur auf den BackboneJS-Bausteinen bereit
  • Extrahiere Muster, die Autoren in ihren Apps verwenden

Marionette, die ich seit Dezember 2011 baue, hat auch ein paar sehr unterschiedliche Ziele und Ideale vor Augen:

  • Verbundanwendungsarchitektur
  • Enterprise Messaging Pattern-Einfluss
  • Modularisierungsoptionen
  • Inkrementelle Nutzung (keine Alles-oder-Nichts-Anforderung)
  • Kein Server-Lock-In
  • Erleichtern Sie es, diese Standardeinstellungen zu ändern
  • Code als Konfiguration / über Konfiguration

Ich sage nicht, dass keines der anderen Frameworks dieselben Ziele verfolgt. Aber ich denke, Marionettes Einzigartigkeit kommt von der Kombination dieser Ziele.

Zusammengesetzte Anwendungsarchitektur

Ich habe mehr als 5 Jahre in Thick-Client, verteilten Softwaresystemen mit WinForms und C # gearbeitet. Ich habe Apps für Desktops, Laptops (Smart-Clients), mobile Geräte und Web-Anwendungen entwickelt, die alle einen zentralen Funktionsumfang teilen und oft mit dem gleichen Server-Backend arbeiten. In dieser Zeit lernte ich den Wert der Modularisierung kennen und ging sehr schnell den Weg des Composite Application Designs.

Die Grundidee besteht darin, das Runtime-Erlebnis Ihrer Anwendung zu "komponieren" und aus vielen kleineren, einzelnen Teilen, die nicht unbedingt voneinander wissen, zu prozessieren. Sie melden sich bei dem gesamten zusammengesetzten Anwendungssystem an und kommunizieren dann über verschiedene entkoppelte Nachrichten und Anrufe.

Ich habe ein wenig darüber in meinem Blog geschrieben und Marionette als eine zusammengesetzte Anwendungsarchitektur für Backbone vorgestellt:

Nachrichtenwarteschlangen / Muster

Die gleichen verteilten Systeme in großem Maßstab nutzten auch Nachrichtenwarteschlangen, Unternehmensintegrationsmuster (Nachrichtenmuster) und Dienstbusse, um die Nachrichten zu verarbeiten. Dies hat vor allem meinen Ansatz zur entkoppelten Softwareentwicklung enorm beeinflusst. Aus dieser Perspektive habe ich begonnen, WinForms-Anwendungen mit nur einem Prozess im Speicher zu sehen, und schon bald hat sich meine Server- und Webanwendungsentwicklung darauf ausgewirkt.

Dies hat sich direkt in das Backbone-Anwendungsdesign übertragen. Ich stelle in Marionette sowohl für das Anwendungsobjekt auf hoher Ebene als auch für jedes Modul, das Sie innerhalb der Anwendung erstellen, einen Ereignisaggregator bereit.

Ich denke über Nachrichten nach, die ich zwischen meinen Modulen senden kann: Befehlsnachrichten, Ereignismeldungen und mehr. Ich denke auch über die serverseitige Kommunikation als Nachrichten mit denselben Mustern nach. Einige der Muster sind bereits in Marionette eingedrungen, einige noch nicht.

Modularisierung

Die Modularisierung von Code ist enorm wichtig. Das Erstellen kleiner, gut gekapselter Pakete, die einen einzigartigen Fokus mit gut definierten Ein- und Ausstiegspunkten haben, ist ein Muss für jedes System von signifikanter Größe und Komplexität.

Marionette bietet Modularisierung direkt durch seine module . Aber ich erkenne auch, dass manche Leute RequireJS mögen und das benutzen wollen. Also biete ich sowohl einen Standard Build als auch einen RequireJS kompatiblen Build an.


MyApp = new Backbone.Marionette.Application();

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

  // your module code goes here

});

(Bisher noch kein Blogbeitrag verfügbar)

Inkrementelle Verwendung

Dies ist eine der Kernphilosophien, die ich in jedem Teil von Marionette erhalte, die ich kann: keine "Alles-oder-Nichts" -Anforderung für den Gebrauch von Marionette.

Backbone selbst verwendet einen sehr inkrementellen und modularen Ansatz mit all seinen Bausteinobjekten. Sie können frei wählen, welche Sie wann verwenden möchten. Ich glaube fest an dieses Prinzip und bemühe mich, dafür zu sorgen, dass Marionette genauso funktioniert.

Zu diesem Zweck sind die meisten der Teile, die ich in Marionette eingebaut habe, so gebaut, dass sie alleine stehen, um mit den Kernstücken von Backbone zu arbeiten und noch besser zusammenzuarbeiten.

Zum Beispiel muss fast jede Backbone-Anwendung eine Backbone-Ansicht an einer bestimmten Stelle auf dem Bildschirm dynamisch anzeigen. Die Apps müssen auch mit dem Schließen alter Ansichten und dem Bereinigen von Speicher fertig werden, wenn ein neuer erstellt wird. Hier spielt Marionette's Region . Eine Region behandelt den Standardcode zum Aufnehmen einer Ansicht, zum Aufrufen von Rendern und zum Stuffing des Ergebnisses im DOM. Dann wird diese Ansicht geschlossen und für Sie aufgeräumt, sofern Ihre Ansicht eine "Schließen" -Methode enthält.


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

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

Aber Sie müssen Marionettes Ansichten nicht verwenden, um eine Region zu verwenden. Die einzige Anforderung ist, dass Sie von Backbone.View an einem Punkt in der Prototypkette des Objekts erweitern. Wenn Sie sich für eine Methode zum close , eine Methode onShow oder andere entscheiden, ruft Marionette's Region Sie zur richtigen Zeit an.

Kein Server-Lock-In

Ich baue Backbone / Marionette Apps auf einer Vielzahl von Servertechnologien:

  • ASP.NET MVC
  • Ruby auf Schienen
  • Rubin / Sinatra
  • NodeJS / ExpressJS
  • PHP / Schlank
  • Java
  • Erlang
  • ... und mehr

JavaScript ist JavaScript, wenn es darum geht, in einem Browser zu laufen. Server-seitiges JavaScript ist ebenfalls großartig, aber es hat keinen Einfluss oder Einfluss darauf, wie ich mein browserbasiertes JavaScript schreibe.

Aufgrund der Vielfalt an Projekten, die ich erstellt habe, und Back-End-Technologien, die meine Kunden verwenden, kann und wird ich Marionette aus irgendeinem Grund nicht in einen einzelnen Server-Side-Technologie-Stack einsperren. Ich werde kein Standardprojekt erstellen. Ich werde kein Rubin-Juwel oder ein NPM-Paket zur Verfügung stellen. Ich möchte, dass die Leute verstehen, dass Marionette keinen bestimmten Back-End-Server benötigt. Es ist browserbasiertes JavaScript und das Backend spielt keine Rolle.

Natürlich unterstütze ich andere, die Pakete für ihre Sprache und ihr Framework bereitstellen. Ich listet diese Pakete im Wiki auf und hoffe, dass die Leute weiterhin Pakete erstellen, wenn sie ein Bedürfnis sehen. Aber das ist Gemeinschaftsunterstützung, nicht direkte Unterstützung von Marionette.

Ändern Sie leicht die Voreinstellungen

In meinem Bemühen, den Standardcode zu reduzieren und vernünftige Standardwerte zu liefern (was ich direkt von Tim Branyens LayoutManager "entlehnt" habe), erkenne ich, dass andere Entwickler leicht andere Implementierungen verwenden müssen als ich.

Ich biete Rendering basierend auf Inline-Tags <script> für Vorlagen, standardmäßig mit Underscore.js-Templating. Sie können dies jedoch ersetzen, indem Sie die Renderer und / oder TempalteCache Objekte in Marionette TempalteCache . Diese beiden Objekte stellen den Kern der Rendering-Funktionen dar, und es gibt Wiki-Seiten, die zeigen, wie dies für bestimmte Template-Engines und verschiedene Arten des Ladens von Templates geändert werden kann.

Mit v0.9 von Marionette wird es noch einfacher. Wenn Sie beispielsweise die Verwendung von Inline-Vorlagenskriptblöcken durch vorkompilierte Vorlagen ersetzen möchten, müssen Sie nur eine Methode im Renderer ersetzen:


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

Jetzt verwendet die gesamte Anwendung vorkompilierte Vorlagen, die Sie an das template Ihrer Ansicht anhängen.

Ich biete sogar eine Marionette.Async-Add-on mit v0.9, mit der Sie asynchron Rendering-Ansichten unterstützen können. Ich bin ständig bestrebt, es so einfach wie möglich zu machen, um die Standardverhalten in Marionette zu ersetzen.

Code als Konfiguration

Ich bin ein Fan von "Konvention über Konfiguration" in bestimmten Kontexten. Es ist ein kraftvoller Weg, Dinge zu erledigen, und Marionette liefert ein bisschen davon - obwohl nicht zu viel, ehrlich gesagt. Viele andere Frameworks - insbesondere der LayoutManager - bieten mehr Konventionen über die Konfiguration als Marionette.

Dies geschieht mit Absicht und Absicht.

Ich habe genug JavaScript-Plugins, Frameworks, Add-Ons und Anwendungen entwickelt, um den Schmerz zu verstehen, wie man versucht, Conventions sinnvoll und schnell zum Laufen zu bringen. Es kann mit Geschwindigkeit gemacht werden, aber in der Regel auf Kosten der Möglichkeit, es zu ändern.

Zu diesem Zweck nehme ich Marionette einen "Code als Konfiguration" -Ansatz vor. Ich biete nicht viele "Konfigurations" -APIs an, in denen Sie ein Objektliteral mit statischen Werten bereitstellen können, die eine Reihe von Verhaltensweisen ändern. Stattdessen dokumentiere ich die Methoden, die jedes Objekt hat - sowohl durch annotierten Quellcode als auch durch die eigentliche API-Dokumentation - mit der Absicht, dir zu sagen, wie du Marionette so verändern kannst, dass es so funktioniert, wie du es willst.

Indem ich eine saubere und klare API für die Marionetten-Objekte zur Verfügung stelle, erschaffe ich eine Situation, in der das Verhalten eines bestimmten Objekts oder einer Marionette als Ganzes relativ einfach und sehr flexibel ersetzt werden kann. Ich opfere die "einfachen" Konfigurations-API-Aufrufe für die Flexibilität, Ihren eigenen Code bereitzustellen, damit die Dinge so funktionieren, wie Sie es möchten.

Sie werden in Marionette kein "configure" oder "options" API finden. Aber Sie werden eine große Anzahl von Methoden finden, die jeweils einen ganz bestimmten Zweck erfüllen, mit sauberen Unterschriften, die es einfach machen, zu ändern, wie Marionette funktioniert.

tutorial dead

Ich hoffe, dass jemand seine Erfahrung mit einigen der neuesten aufkommenden backbone.js-Varianten da draußen teilen kann. Ich habe einige gute Erfahrungen mit Backbone / Underscore / in mehreren Projekten gemacht und möchte den nächsten Schritt in Richtung fortgeschrittener Lösungen für komplexe Anwendungsstrukturen gehen.

Ich weiß, dass folgende Frameworks verfügbar sind:

Und wahrscheinlich habe ich ein paar verpasst.

Es gibt eine kurze Einführung über die Unterschiede hier:

aber es ist sehr allgemein. Ich habe mich gefragt, ob jemand seine Erfahrungen mit realen Anwendungen unter Verwendung dieser Frameworks teilen kann.

Was ist der Vorteil, wenn man sich für einen anderen entscheidet? Wann wird Marionette eine bessere Lösung als Chaplin sein, oder warum sind Veteranen besser für bestimmte Anwendungen, zum Beispiel.

Sicher, die offensichtliche Antwort lautet: " Nutze das Beste für deine Bedürfnisse ", aber ich habe keine Erfahrung mit diesen Frameworks, um ihre Stärke / ihren Zweck / ihre Vorteile oder bevorzugten Szenarien zu kennen.

Vielen Dank!

Edit 1: diesen Beitrag gefunden: Backbone.Marionette vs Backbone-Boilerplate

Edit 2: Antwort von Mathias schafer (Chaplin) per Post:

Kurz gesagt, die aktuelle Struktur ist der Version 1.0 nahe, da sie bereits in der Produktion verwendet wird. Wir planen nicht, große neue Features hinzuzufügen oder API-Änderungen bis 1.0 zu ändern.

Marionette ist mit Sicherheit die umfangreichste und stabilste Bibliothek auf dem Markt. Es behandelt mehrere Aspekte der JS-App-Entwicklung mit Backbone. Zum Beispiel hat es eine starke Sichtschicht, die Backbone selbst völlig leer lässt. Natürlich werden Sie feststellen, dass einige der Aspekte Ihren Anforderungen nicht gerecht werden und Sie vielleicht das Bedürfnis haben, eine Struktur um Marionette aufzubauen.

Im Gegensatz dazu konzentriert sich Chaplin auf einen eher kleinen, aber sehr wichtigen Aspekt von Backbone-Apps, nämlich die gesamte App-Struktur und den Modullebenszyklus. In dieser Hinsicht ist Chaplin sehr opioniert und ähnelt eher einem Framework als einer Bibliothek (wie in "Ihr Code ruft eine Bibliothek auf, ein Framework nennt Ihren Code"). Chaplin bietet einige zentrale Klassen, die über einzelnen Anwendungsmodulen liegen und den gesamten App-Status steuern. Dadurch erhält Ihre App eine herkömmliche Struktur wie zum Beispiel Ruby on Rails.

In Chaplin deklarieren Sie einige Routen, die Controllern zugeordnet sind, und Chaplin startet den Controller, sobald die Route übereinstimmt. Es kümmert sich auch um die Entsorgung von alten Controllern und das Anzeigen und Verbergen von Hauptansichten, die ein Controller erstellen soll. Das ist die Grundidee, aber Chaplin kümmert sich um die hässlichen Details, um den reibungslosen Ablauf zu gewährleisten.

Es gibt zwei Prinzipien, die mit dieser Struktur einhergehen: - Modularisierung, Entkopplung und Sandboxing - Modulübergreifende Kommunikation mit Publish / Subscribe und Mediator (s)

Natürlich sind diese Muster in der Softwareentwicklungswelt nicht neu, und Chaplin ist nicht die einzige Bibliothek, die sie auf Backbone.js Apps anwendet.

Chaplin bietet auch Verbesserungen für den View-Layer, zum Beispiel ein hochentwickeltes CollectionView, aber insgesamt nicht so viel wie Marionette mit seinen Regionen und Layouts. Aber es ist relativ einfach, solche Meta-Klassen mit den von Chaplin Views bereitgestellten Mitteln zu schreiben.




Ich habe die verschiedenen mit Backbone.js erstellten Frameworks studiert und die Vertebrae für ein Projekt bei HauteLook erstellt. Die Projektziele beinhalteten ... dynamisches Laden von Skripten, AMD-Modul-Format, Abhängigkeitsverwaltung, Build mit meist Open-Source-Bibliotheken, Organisieren von Code in Paketen, Optimieren und Erstellen für eine oder mehrere Einzelseiten-Anwendungen, Host auf vollständig zwischengespeicherten Servern, zB kein Server -Skripting mit nur einer API für Daten, und die Funnest für mich, verwenden verhaltensorientierte Entwicklung für das Projekt. Es gibt eine Beschreibung des Projekts unter: http://www.hautelooktech.com/2012/05/24/vertebrae-front-end-framework-built-with-backbone-js-and-requirejs-using-amd/

Unser Problem:

Ausgewählte Bibliotheken (jQuery, Underscore.js, Backbone.js, RequireJS, Moustache) bieten Module laden, Abhängigkeitsverwaltung, Anwendungsstruktur (für Modelle, Sammlungen, Ansichten und Routen), asynchrone Interaktionen mit API, verschiedene Dienstprogramme und Objekte zum Verwalten von asynchronem Verhalten , zB (Promises) Deferreds, Callbacks. Die verbleibende Logik, die zur Vervollständigung des Frameworks benötigt wird, umfasst:

  • ein Objekt (Modell) zum Verwalten des Zustands der Einzelseitenanwendung;
  • ein Layout-Manager zum Anzeigen, Anordnen / Überblenden und Löschen von Ansichten und
  • Controller, die auf Routen reagieren, den Anwendungsstatus abrufen / festlegen und die Arbeit an den Layout-Manager übergeben.

Unsere Lösungen (implementiert in Wirbel):

Anwendungsstatus-Manager -

Der Anwendungsmanager speichert Daten im Speicher und behält auch Daten im Browserspeicher bei, um eine Ressource für gemeinsame Daten / Metadaten bereitzustellen. Bietet außerdem Daten (Status) zum Rekonstruieren der Seitenansichten basierend auf vorherigen Interaktionen (z. B. ausgewählte Registerkarte, angewendete Filter). Der Anwendungsstatus-Manager bietet eine Strategie für Ressourcen zum Abrufen des Status. Beabsichtigt, als Staatsmaschine zu agieren.

Layoutmanager -

Der Layout-Manager hat eine oder mehrere Ansichten sowie Dokument (DOM) -Ziele für jede (gerenderte) Ansicht. Eine Seite kann zwischen vielen Ansichten wechseln, so dass der Layout-Manager die Ansichtszustände verfolgt, z. B. gerendert, nicht gerendert, angezeigt, nicht angezeigt. Sie können den Layout-Manager verwenden, um Ansichten, die ein Site-Besucher sehr wahrscheinlich anfordert, z. B. Tab-Änderungen auf einer Seite, zu laden und zu rendern. Der Übergang zwischen den Ansichtszuständen wird von diesem Objekt verwaltet. Ein gesamtes Layout kann gelöscht werden, sodass Ansichtsobjekte und ihre Bindungen entfernt werden, wodurch diese Objekte für die Speicherbereinigung vorbereitet werden (wodurch Speicherlecks verhindert werden). Der Layout-Manager kommuniziert auch den Ansichtszustand mit den Controllern.

Controller -

Ein Controller-Objekt wird von einer Route-Handler-Funktion aufgerufen und ist dafür zuständig, den relevanten Status (Anwendungsmodelle) zum Generieren einer Seite (Layout) zu erhalten (auch verantwortlich für das Setzen des Status bei Routenänderungen). Der Controller übergibt abhängige Daten (Modelle / Sammlungen) und konstruierte Ansichtsobjekte für eine angeforderte Seite an den Layout-Manager. Als Nebeneffekt verhindert die Verwendung von Controllern, dass das Routenobjekt aufgebläht und verheddert wird. Eine Route sollte einem Controller zugeordnet werden, der dann die Seitenansicht startet und die Routenbehandlungsfunktionen schlank hält.

Die Todos App wird sowohl im Dev-Modus gehostet als auch auf Heroku ...

Viele der Konzepte in den anderen Frameworks sind ausgeliehen, z. B. die Notwendigkeit, Ansichten zu destrukturieren, um Speicherlecks in der Vorschau anzuzeigen, wie von Derick Bailey - http://lostechies.com/derickbailey/ ; der Layout Manager von Tim Branyen http://tbranyen.github.com/backbone.layoutmanager/

Zusammenfassend ist Backbone.js ein Tool in Ihrer Anwendung. Die Backbone.js-Bibliothek bietet nicht die gesamte Architektur, die Sie zum Erstellen einer Anwendung benötigen, bietet aber großartige Interaktionen mit einer API und einer soliden Codestruktur für ... Views (agieren wie Controller) und Ihre Datenebene Models and Collections und schließlich Routes. Wir haben Vertebrae gebaut, um die Ziele unseres Projekts zu erfüllen, und beschlossen, den Code als Rahmen für andere zu nutzen, zu lernen oder was auch immer.

Die Antwort auf deine Frage ist meiner Meinung nach, von allen Frameworks zu lernen und zu verwenden, was du brauchst, um deine Ziele zu erreichen, wenn du feststellst, dass deine Projektziele eng mit einem der mit Backbone aufgebauten Frameworks harmonieren Es gibt großartige Beispiele, die von der Community geteilt werden. Oder wenn Sie sich in Richtung Ihrer Bewerbung ein wenig verloren fühlen, dann wählen Sie etwas mehr meinungsorientiert und strukturiert vielleicht Ember.js. Das Tolle ist, dass es eine gute Auswahl an Optionen gibt, die Ihnen helfen, mit einem (MVX) MVC-ähnlichen Muster mit JavaScript zu programmieren.







Related