Alternative „architektonische“ Ansätze für JavaScript-Clientcode?

StackOverflow https://stackoverflow.com/questions/32540

Frage

Wie ist Ihr JavaScript-Code organisiert?Folgt es Mustern wie MVC oder etwas anderem?

Ich arbeite nun schon seit einiger Zeit an einem Nebenprojekt, und je weiter ich komme, desto mehr hat sich meine Webseite in eine voll funktionsfähige Anwendung verwandelt.Im Moment bleibe ich dabei jQuery, Allerdings wächst die Logik auf der Seite so weit, dass eine gewisse Organisation, oder ich wage es zu sagen, „Architektur“ erforderlich ist.Mein erster Ansatz ist „MVC-ish“:

  • Das „Modell“ ist ein JSON-Baum, der mit Helfern erweitert wird
  • Die Ansicht besteht aus dem DOM und den Klassen, die es optimieren
  • Der Controller ist das Objekt, mit dem ich die Ereignisverarbeitung verbinde und die Ansichts- oder Modellmanipulation anstoße

Ich bin jedoch sehr daran interessiert, wie andere Leute umfangreichere JavaScript-Apps erstellt haben.Ich interessiere mich nicht für GWT oder andere serverorientierte Ansätze ...nur im Ansatz von „JavaScript + <generic web service-y thingy here>“

Notiz:Vorhin habe ich gesagt, dass JavaScript „nicht wirklich OO, nicht wirklich funktionsfähig“ ist.Ich glaube, das hat alle abgelenkt.Sagen wir es so: Da JavaScript in vielerlei Hinsicht einzigartig ist und ich einen stark typisierten Hintergrund habe, möchte ich keine Paradigmen erzwingen, die ich kenne, die aber in sehr unterschiedlichen Sprachen entwickelt wurden.

War es hilfreich?

Lösung

..aber Javascript hat viele Facetten Sind OO.

Bedenken Sie:

var Vehicle = jQuery.Class.create({ 
   init: function(name) { this.name = name; } 
});

var Car = Vehicle.extend({ 
   fillGas: function(){ 
      this.gas = 100; 
   } 
});

Ich habe diese Technik verwendet, um Javascript-Klassen auf Seitenebene zu erstellen, die ihren eigenen Status haben. Dies hilft, ihn in Grenzen zu halten (und ich identifiziere oft Bereiche, die ich wiederverwenden und in andere Klassen einfügen kann).

Dies ist auch besonders nützlich, wenn Sie über Komponenten/Serversteuerelemente verfügen, die über ein eigenes Skript verfügen, das ausgeführt werden muss, Sie jedoch möglicherweise mehrere Instanzen auf derselben Seite haben.Dadurch bleibt der Staat getrennt.

Andere Tipps

JavaScriptMVC ist eine großartige Wahl für die Organisation und Entwicklung einer umfangreichen JS-Anwendung.

Das Architekturdesign ist sehr gut durchdacht.Es gibt 4 Dinge, die Sie jemals mit JavaScript tun werden:

  1. Reagieren Sie auf ein Ereignis
  2. Daten anfordern/Dienste manipulieren (Ajax)
  3. Fügen Sie der Ajax-Antwort domänenspezifische Informationen hinzu.
  4. Aktualisieren Sie das DOM

JMVC unterteilt diese in die Muster Modell, Ansicht und Controller.

Der erste und wahrscheinlich wichtigste Vorteil ist der Controller.Controller verwenden die Ereignisdelegation. Anstatt also Ereignisse anzuhängen, erstellen Sie einfach Regeln für Ihre Seite.Sie verwenden auch den Namen des Controllers, um den Umfang dessen einzuschränken, woran der Controller arbeitet.Dadurch wird Ihr Code deterministisch. Wenn Sie also sehen, dass ein Ereignis in einem „#todos“-Element auftritt, wissen Sie, dass es einen Todos-Controller geben muss.

$.Controller.extend('TodosController',{
   'click' : function(el, ev){ ... },
   '.delete mouseover': function(el, ev){ ...}
   '.drag draginit' : function(el, ev, drag){ ...}
})

Als nächstes kommt das Modell.JMVC bietet eine leistungsstarke Klasse und ein Basismodell, mit denen Sie Ajax-Funktionalität schnell organisieren (Nr. 2) und die Daten mit domänenspezifischer Funktionalität (Nr. 3) umschließen können.Wenn Sie fertig sind, können Sie Modelle von Ihrem Controller verwenden wie:

Todo.findAll({after:new Date()}, myCallbackFunction);

Sobald Ihre Todos zurückkommen, müssen Sie sie schließlich anzeigen (#4).Hier verwenden Sie die Ansicht von JMVC. 

'.show click' : function(el, ev){ 
   Todo.findAll({after: new Date()}, this.callback('list'));
},
list : function(todos){
   $('#todos').html( this.view(todos));
}

In 'views/todos/list.ejs'

<% for(var i =0; i < this.length; i++){ %>
   <label><%= this[i].description %></label>
<%}%>

JMVC bietet viel mehr als nur Architektur.Es hilft Ihnen in jedem Teil des Entwicklungszyklus bei:

  • Codegeneratoren
  • Integrierte Browser-, Selenium- und Rhino-Tests
  • Dokumentation
  • Skriptkomprimierung
  • Fehler melden

MochiKit ist großartig – und war sozusagen meine erste Liebe, was JS-Bibliotheken betrifft.Aber ich habe festgestellt, dass MochiKit zwar eine sehr ausdrucksstarke Syntax hat, sich für mich aber nicht annähernd so angenehm anfühlte wie Prototype/Scriptaculous oder jQuery.

Ich denke, wenn Sie Python kennen oder mögen, dann ist MochiKit ein gutes Werkzeug für Sie.

Vielen Dank an alle für eure Antworten.Nach einiger Zeit möchte ich veröffentlichen, was ich bisher gelernt habe.

Bisher sehe ich einen sehr großen Unterschied darin, so etwas wie zu verwenden Ext, und andere mögen JQuery-Benutzeroberfläche, Skriptakulär, MochiKit, usw.

Bei Ext ist der HTML-Code nur ein einzelner Platzhalter – die Benutzeroberfläche kommt hierher.Von da an, alles wird in JavaScript beschrieben.Die DOM-Interaktion wird unter einer anderen (möglicherweise stärkeren) API-Ebene minimiert.

Bei den anderen Kits beginne ich damit, ein bisschen HTML-Design zu machen und dann das DOM direkt mit schicken Effekten zu erweitern oder einfach die Formulareingabe hier oder eine Ergänzung dort zu ersetzen.

Die größten Unterschiede treten auf, wenn ich mich mit der Ereignisbehandlung usw. befassen muss.Da Module miteinander „sprechen“ müssen, muss ich mich vom DOM entfernen und es in Stücke abstrahieren.

Ich stelle fest, dass viele dieser Bibliotheken auch einige interessante Modularisierungstechniken enthalten.Eine sehr klare Beschreibung wird auf der Ext-Website bereitgestellt, die Folgendes enthält: eine ausgefallene Möglichkeit, Ihren Code mit Modulen zu „schützen“..

Ein neuer Player, den ich vollständig evaluiert habe, ist Sproutcore.Es scheint ein Ext-in-Ansatz zu sein, bei dem das DOM ausgeblendet ist und Sie sich hauptsächlich mit der API des Projekts befassen möchten.

Tristan, Sie werden feststellen, dass JavaScript bei der Architektur als MVC-Anwendung in einem Bereich tendenziell zu kurz kommt: dem Modell.Der am schwierigsten zu handhabende Bereich ist das Modell, da die Daten nicht in der gesamten Anwendung bestehen bleiben und sich die Modelle naturgemäß auf der Clientseite ziemlich konsistent zu ändern scheinen.Sie könnten standardisieren, wie Sie Daten vom Server übergeben und empfangen, aber dann gehört das Modell nicht wirklich zu JavaScript, sondern zu Ihrer serverseitigen Anwendung.

Ich habe vor einiger Zeit einen Versuch gesehen, bei dem jemand ein Framework für die Modellierung von Daten in JavaScript erstellt hat, ähnlich wie SQLite zur Anwendung gehört.Es war wie Model.select( "Product" ) und Model.update( "Product", "Some data..." ).Es handelte sich im Grunde um eine Objektnotation, die eine Reihe von Daten enthielt, um den Status der aktuellen Seite zu verwalten.Sobald Sie jedoch eine Aktualisierung durchführen, gehen alle Daten verloren.Ich bin wahrscheinlich mit der Syntax nicht einverstanden, aber Sie verstehen, worauf es ankommt.

Wenn Sie jQuery verwenden, ist Bens Ansatz wirklich der beste.Erweitern Sie das jQuery-Objekt mit Ihren Funktionen und Eigenschaften und unterteilen Sie dann Ihre „Controller“.Normalerweise mache ich das, indem ich sie in separate Quelldateien lege und sie Abschnitt für Abschnitt lade.Wenn es sich beispielsweise um eine E-Commerce-Site handelte, hätte ich möglicherweise eine JS-Datei voller Controller, die die Funktionalität für den Checkout-Prozess verwalten.Dadurch bleiben die Dinge tendenziell leicht und einfach zu verwalten.

Nur eine kurze Klarstellung.

Es ist durchaus möglich, GWT-Apps zu schreiben, die nicht serverorientiert sind.Ich gehe davon aus, dass Sie mit serverorientiert GWT RPC meinen, das ein Java-basiertes Back-End benötigt.

Ich habe GWT-Apps geschrieben, die allein auf der Clientseite sehr „MVC-mäßig“ sind.

  • Das Modell war ein Objektgraph.Obwohl Sie in Java programmieren, liegen die Objekte zur Laufzeit in Javascript vor, sodass weder auf der Client- noch auf der Serverseite eine JVM erforderlich ist.GWT unterstützt auch JSON mit vollständiger Parsing- und Manipulationsunterstützung.Sie können problemlos eine Verbindung zu JSON-Webservices herstellen, siehe 2 für ein JSON-Mashup-Beispiel.
  • Die Ansicht bestand aus Standard-GWT-Widgets (plus einigen unserer eigenen zusammengesetzten Widgets).
  • Die Controller-Ebene wurde sauber vom View-via-Observer-Muster getrennt.

Wenn Ihr „stark typisierter“ Hintergrund Java oder eine ähnliche Sprache ist, sollten Sie GWT meiner Meinung nach für große Projekte ernsthaft in Betracht ziehen.Für kleine Projekte bevorzuge ich normalerweise jQuery.Bevorstehende GWTQuery das mit GWT 1.5 funktioniert, könnte sich daran ändern, allerdings nicht in naher Zukunft, da es eine Fülle von Plugins für jQuery gibt.

Ich bin mir nicht 100 % sicher, was Sie hier meinen, aber ich muss sagen, dass meine Webseiten, nachdem ich in den letzten 6 Jahren ASP.NET verwendet habe, jetzt größtenteils von JavaScript gesteuert werden, sobald die grundlegende Seitendarstellung vom Server durchgeführt wird.Ich verwende JSON für alles (seit etwa 3 Jahren) und verwende MochiKit für meine kundenseitigen Bedürfnisse.

Übrigens JavaScript Ist OO, aber da es eine prototypische Vererbung verwendet, wird es nicht auf diese Weise gewürdigt.Ich würde auch behaupten, dass es auch funktional ist, es hängt alles davon ab, wie man es schreibt.Wenn Sie wirklich an funktionalen Programmierstilen interessiert sind, schauen Sie hier vorbei MochiKit - Es könnte Ihnen gefallen;Es lehnt sich stark an die funktionale Programmierseite von JavaScript an.

Lizenziert unter: CC-BY-SA mit Zuschreibung
Nicht verbunden mit StackOverflow
scroll top