Ich habe mich schon eine ganze Weile gefragt und habe noch keine Antwort gefunden.
Warum verwenden Sie Backbone.js genau in einer Rails-Anwendung? Ist es, Funktionalität zu erweitern, ein MVC-Muster für Ihr JS zu haben, bessere APIs zu bauen ...?
Im Moment kann ich keinen Grund sehen, warum Sie es für etwas verwenden möchten, weil ich glaube, dass ich das Konzept von Backbone.js nicht verstehe
Der große Vorteil von rails besteht darin, dass Sie eine Plattform und eine Sprache verwenden, die den Server-Code verarbeiten und den Client-Code generieren können (mithilfe der Ansichten).
Zweifellos beginnt dieser theoretische Vorteil schnell zu schwinden, wenn Sie Ihre Benutzererfahrung mit Javascript und jQuery verbessern wollen. Also musst du eigentlich noch zwei Sprachen lernen.
Aber trotzdem: alle Ihre Modelle, Geschäftsregeln, ... werden auf der Serverseite in Ruby behandelt. Dies bedeutet auch, dass der Server immer erreichbar sein muss.
Was ein Java-Script / Client-MVC (wie Backbone.js, Sproutcore, ...) Ihnen bieten kann, ist ein nativeres Anwendungsgefühl. Eine einzelne Webseitenanwendung, wie z.B. Google Mail Abhängig von Ihren Anforderungen gibt es einige sehr nützliche Anwendungsfälle für eine solche Plattform. Z.B. An Orten oder Geräten mit geringer Konnektivität könnte es (mit HTML5) sehr nützlich sein, eine Webanwendung zu haben, die nicht ständig "online" sein muss. Es könnte Daten speichern und in den lokalen Speicher und zurück zum Server / Datenbank synchronisieren, wenn das Gerät wieder online ist.
Aber es gibt einen großen Nachteil bei der Entwicklung von Client-MVC-Anwendungen in Kombination mit Rails: Sie müssen einige Doppelentwicklungen durchführen (dasselbe gilt, wenn Sie flex / silverlight verwenden). Ihre Modelle müssen sowohl auf dem Server als auch auf dem Client definiert werden. Ich kann mir vorstellen, dass einige Verbesserungen vorgenommen werden können, da auf dem Client MVC tatsächlich Presenter-Klassen verwendet werden, die auf der Serverseite in verschiedenen Modellen / Tabellen gespeichert werden können. Aber es wird immer noch doppelte Logik geben, Modelle, ...
Deshalb denke ich, dass es für die meisten Anwendungen im Moment nicht ratsam ist, zu einem Client-MVC-Framework zu wechseln. Es wird viel mehr Arbeit sein.
Aber wenn Sie das Aussehen einer echten nativen Anwendung oder einer One-Page-Web-Anwendung benötigen, dann ist ein JavaScript-Client-MVC-Framework der richtige Weg. Und wenn Sie ein Client-MVC-Framework benötigen, würde ich Sproutcore vorschlagen.
Um Ihre aktuelle Rails-Anwendung einfach zu ajaxieren (reduziert die Ladezeit jeder einzelnen Seite), werfen Sie einen Blick auf pjax-rails .
(besser spät als nie - hoffe, das ist nützlich für jemanden) Die Beschreibung auf Backbonejs Website scheint wie viele Wörter zusammengeworfen ohne viel Bedeutung. Es gibt einen großen Hype um ihn herum, aber was ist los?
Hinter dem Backbone steht die These, dass moderne, einseitige Web-Apps (Think Gmail) schnell zu einer sehr komplexen Interaktion zwischen der Synchronisierung von dom-Elementen, UI-Ereignissen und dem Backend werden. Sie könnten leicht feststellen, dass Sie Daten innerhalb der Dom-Elemente speichern und dann die Daten irgendwie wieder extrahieren müssen, um die Datenbank zu aktualisieren. Wenn Sie Ihren Code nicht sehr sorgfältig strukturieren, werden Sie schnell mit Spaghetti-Code voller komplexer Bindungen oder Code ohne Backbone enden.
Mit Backbone-Modellen, Sammlungen und Ansichten erhalten Sie eine gut durchdachte Struktur, in der Sie arbeiten können. So können Sie große Apps erstellen, ohne von ihrer Komplexität überwältigt zu werden. Außerdem passt es wunderbar zu einem erholsamen Backend.
Tags und Links ruby ruby-on-rails backbone.js