Für ein kürzlich durchgeführtes Projekt haben wir uns entschieden, Backbone.js zu verwenden, um die Client-Seite unserer RESTful Web-Anwendung zu strukturieren. Backbone.js ist im Moment sehr in Mode und da wir bereits ein internes Spielzeugprojekt hatten, das Backbone.js verwendete, erwarteten wir keine großen Probleme. Aber natürlich gab es Probleme. Egal wie gut das Beispielmaterial ist, es ist kein Ersatz für tatsächliche Erfahrung. Wir haben diese Erfahrung durch unsere Fehler gesammelt, und obwohl es im Internet bereits eine Reihe von Artikeln über die Stärken, Schwächen und Fallstricke von Backbone.js gibt, die ich im Folgenden aufführe, bedeutet ein weiterer Artikel hoffentlich gute Ratschläge für diejenigen, die neu bei Backbone.js sind, und einen Anstoß in die richtige Richtung.
Wenn Sie Backbone.js (und die zugrundeliegenden Programme) noch nicht kennen, dann ist das Buch von Addy Osmani ein guter Einstieg.
Arbeiten Sie nicht außerhalb Ihres Modells
Das Wichtigste ist wahrscheinlich, dass Backbone.js ein clientseitiges MVC/MVP-Framework ist und Sie es auch als solches verwenden sollten. Das bedeutet, dass alles, was Ihre Anwendung tut, über Backbone.js läuft. Eine verbreitete Ansicht über Backbone.js ist, dass seine Anwendungen ereignisgesteuert sein sollten. Ansichten sollten sich nicht selbst verändern oder auf andere Ansichten verweisen. Stattdessen sollten alle Aktionen mit entsprechenden Ereignissen verbunden sein, die den Zustand des Modells ändern, das sich dann um die Aktualisierung der Ansicht(en) kümmert. Die Kommunikation zwischen den Ansichten kann über einen Ereignis-Aggregator erfolgen. Wenn Sie diese Backbone-zentrierte Denkweise nicht beibehalten, könnten Sie anfangen, kleine Teile von seiten-spezifischen Skripten in Ihre Vorlagen einzubauen, von denen Ihr Modell keine Kenntnis hat. Dies könnte Ihr Modell und Ihre Ansicht in einen inkonsistenten Zustand versetzen. Und warum sollten Sie Skripte aus Ihrer Vorlage ausführen, wenn Sie mit Backbone.js Ereignisse an jedes Objekt binden können?
Manipulieren Sie den Router nicht
Der Router hat zwei Hauptfunktionen in Backbone.js. Die eine besteht darin, dass eine URL direkt von außerhalb Ihrer Website aufgerufen werden kann. Die andere ist das Hinzufügen von URLs zum Verlauf Ihres Browsers für eine bessere Navigation. Wenn Sie den Router aus irgendeinem Grund manuell zu einer anderen URL leiten müssen, sollte dies nur geschehen, weil Sie diese URL im Browserverlauf benötigen, und fast nie, um die Aktion eines Benutzers zu simulieren, die durch Klicken ausgeführt wird. Der beabsichtigte Kontrollfluss sollte vom Ereignis-Handler der Ansicht zum Modell und über den Ereignis-Listener der Ansicht zurück zur Ansicht gehen. Dieser ausgezeichnete Artikel von Derick Bailey hilft Ihnen, die Funktion von Backbone zu verstehen.
Denken Sie bei der Gestaltung Ihrer REST-Schnittstelle an Backbone.js
Wie in der Funktion .sync und in diesem Beitrag dokumentiert, arbeitet Backbone.js gut mit REST zusammen, vor allem wenn die Schnittstelle richtig auf die Verwendung von Substantiven, Ids und den dafür verwendeten Standard-CRUD-Operationen ausgelegt ist. Wenn Ihr REST-Design nicht ganz passt, kann eine Kombination aus der Funktion .url> des Modells und/oder Routen den Zweck erfüllen, aber Sie halten sich besser an den Vorschlag von Backbone (und an ein gutes REST-Design im Allgemeinen).
Fazit
Backbone.js ist ein großartiges Framework, das Sie verwenden können, wenn Ihr client-seitiges JavaScript den Punkt erreicht, an dem es zu viel Spaghetti mit Matschsauce wird. Man kann zwar argumentieren, dass die Dokumentation nicht immer klar genug ist, was die Verwendungszwecke der Modelle, Router und Ansichten angeht, aber es gibt genügend Informationen, die Ihnen helfen, den richtigen Weg für Ihre Anwendung zu finden. Ich für meinen Teil kann es kaum erwarten, Backbone.js wieder zu verwenden und diese Erfahrungen in die Praxis umzusetzen.
Verfasst von
Tom Bestebreurtje
Tom Bestebreurtje joined Xebia on November 7, 2011 as an Apprentice Consultant. This means he will spend time learning about the many technologies employed at Xebia, as well as finding new and interesting ones to use. He studied at the VU University Amsterdam where he received a Masters degree in computer science with a specialization in multimedia. Prior to joining Xebia, he co-founded his own business where he developed an online shopping blog. Tom is interested in mobile computing, augmented reality and the visualization of information. His spare time is most likely spent on games, music, guitars and travel. Destination unknown and open to suggestions on all accounts.
Contact



