Macht es Sinn, sich zu integrieren backbone.js mit ASPNET MVC?
Ich bin kein Experte in diesen Bausteinen, aber auf den ersten Blick scheint es mir:
-
ASPNET MVC will zum generieren der sichten und verwalten der Modelle für eine app auf der server-Seite. Sie sieht den browser als eine etwas dumme Präsentation-Motor, für einen Verbraucher, der die Ansichten, die bereitgestellt werden, durch den server.
-
backbone.js möchte zum generieren der sichten und verwalten der Modelle im browser. Sie auf der server-Seite als eine ziemlich dumme REST-basierten Persistenz-engine.
Dies scheint wie eine vereinfachende Sicht. Ich bin sicher, es ist nicht die ganze Geschichte.
Was sind die wirklichen Chancen für eine Integration dieser beiden Dinge? Macht es Sinn, es zu tun?
Oder gibt es zu viel überschneidungen zwischen Ihnen, die für Sie Sinn machen?
Ich mag, um zu sehen, eine Analyse oder Diskussion, wenn jemand kann sich mich.
- +1 freue mich auf die Antworten. Haben Sie auch erwogen, knockout.js und spine.js? Wirbelsäule scheint zu sein, weniger bekannt als Rückgrat, aber ich habe gelesen, gute Dinge über Sie.
- Zwar nicht unbedingt direkt mit deiner Frage, es ist eine gute Diskussion über backbone und knockout-hier: stackoverflow.com/questions/5112899/... in diesem Sinne, ich freue mich auch auf die Antworten auf diese.
Du musst angemeldet sein, um einen Kommentar abzugeben.
Während ich nicht sprechen backbone.js ich kann Ihnen sagen, dass ich verwendet habe, knockout, um große Wirkung in Kombination mit ASP.NET MVC. Jeder ASP.NET Anwendung, die ich gesehen habe bisher verwendet eine Mischung von client-side und server-side-view-generation. Es gibt immer wieder Zeiten geben, wo Ihr bequemer zu sichten erzeugen server-Seite. Nehmen Sie zum Beispiel bedingte UI-Elemente, basierend auf, ob oder ob nicht ein Benutzer authentifiziert, oder ob Sie eine spezielle Erlaubnis. Sie können nicht wollen, ein web-versierte Benutzer in der Lage sein zu erforschen Ihre client-side-templates und die Funktionen sind Sie nicht immer. Sicher, Sie könnten dies umgehen, indem asynchron laden verschiedener client-Vorlagen, bla bla, oder wind geschrieben, der server-side-code für die Generierung der client-Seite Vorlagen... Außerdem, wenn SEO bedeutet nichts für Sie, Sie kann küssen client-side templating (von selbst), auf Wiedersehen.
Also der sweet-spot ist, meiner Meinung nach, ist etwas, das tut beiden gut. In meiner Erfahrung habe ich gefunden ASP.NET MVC zu excel-bei beiden.
Warum ASP.NET MVC ist genial
return Json(model)Durch die Verwendung eines client-side-framework für view-generation wirklich alles, was Sie verpassen ist Gestochen. Sie können sogar nutzen layouts zu einem gewissen Grad.
Ansatz, den ich zur Entwicklung mit ASP.NET MVC ist zu starten, indem Sie die Anwendung der Arbeit der server-Seite. Dies zwingt Sie zu denken, Sie möchten, dass Ihre URL-Struktur, was verdient ein controller, was Ihre Routen werden sollte. Es bedeutet auch, erhalten Sie den Vorteil der Typsicherheit und auto-vervollständigen-während der ersten iteration der Ansichten. Am Ende dieser übung haben Sie eine einfache, standards-konforme Lösung (hoffentlich), dass funktioniert auf jedem Gerät, auf den Menschen bekannt, dass Google nicht genug bekommen können.
Sodann habe ich über die Einnahme eine inkrementelle Ansatz zur Umsetzung Scheiben client-seitige Funktionalität. Auf der client-Seite habe ich einige javascript schreiben zu entführen eine Anforderung, ich möchte in einem AJAX-request, und Griff die Antwort mit eine übersetzte version der Razor view. Auf der server-Seite nehme ich ein convention-basierten Ansatz, der eine Aktion filter. Das action-filter ist in etwa folgende:
Mit diesem Ansatz können Sie hinzufügen von AJAX-Funktionalität ohne änderung einer einzigen Zeile code im Controller. Ein alternativer Ansatz ist zu Folgen, die Thunderdome AUFTRAGGEBER und haben eine ActionInvoker verantwortlich für die Verpackung des Modells in ein entsprechendes Ergebnis geben, basierend auf den request-Kontext. Ich habe noch nicht herausgefunden, wie server-side-navigation (Weiterleitungen) passen mit diese Vorgehensweise aber.
Der Abfälle, beginnend mit einem server-side-Implementierung ist, du bist Verdoppelung in Aussicht generation-code (Razor + js-basierte Vorlage). Je nachdem, wie viel von Ihrer Anwendung, die Sie umsetzen wollen, auf dem client, der dies kann oder kann nicht ein problem sein. Spark ist die Ausnahme, Sie können tatsächlich bekommen es zu generieren von client-Vorlagen für Sie! Der Nachteil an Spark ist, dass Sie verlieren, intellisense (gibt es ein plugin für, aber seinen Mist), das ist ein nicht unerheblicher Verlust, plus ich lieber nur Razor (seine Backen, braucht nicht konfiguriert zu werden, und ist nicht Weg jederzeit schnell).
Habe ich verwendet asp.net mvc-KO und bakcbone für verschiedene Projekte und es kommt alles auf die Natur des Projekts am Ende. Server stack gehen nicht aus der box, sobald Sie Ihre workflows starten immer komplexer, oder Sie sind zu bieten UX im Gegensatz zu einfachen Daten-Daten-zentrierte Anwendungen. Wenn das Projekt beinhaltet ein hohes UX backbonejs können Sie es.. Nachteil ist, dass es keine gut definierten zentralen Leitlinien für die, die Sie haben zu gehen durch die Hölle von blogs, um Sachen zu erledigen .. Für herkömmliche apps können Sie stick zu KO. Btw es gibt plugins, die mock-KO für backbonejs .. ich beziehe mich auf bacjbone.modelbinder wieder müssen Sie integrieren für Ihre selbst ist, Weil MS nicht die Mühe überhaupt.