Ich mache eine ziemlich komplexe Emberjs-Anwendung und binde sie an ein Backend von APIs.

Die API-Aufrufe sind normalerweise nicht an ein bestimmtes Modell gebunden, sondern können Objekte verschiedener Typen in verschiedenen Abschnitten der Antwort zurückgeben, z. Ein Aufruf der Ereignis-API würde Ereignisse zurückgeben, aber auch Medienelemente und Personen, die an diesen Ereignissen beteiligt sind.

Ich habe gerade mit dem Projekt begonnen und möchte eine fachkundige Anleitung erhalten, wie Probleme am besten getrennt werden können, um eine saubere, wartbare Codebasis zu erhalten.

Ich gehe so vor:

Modelle: Behandelt Datensätze im Wesentlichen mit ihren Feldern und anderen berechneten Eigenschaften. Models sind jedoch nicht für die Abgabe von Anfragen verantwortlich.z.B. Einzelperson, Ereignis, Bild, Beitrag usw.Shops: Sie sind im Wesentlichen Caches. Zum Beispiel eineventStore würde alle bisher vom Server empfangenen Ereignisse (von möglicherweise unterschiedlichen Anforderungen) in einem Array und auch in einem Hash von Ereignissen speichern, die von indiziert wurdenid.z.B. individualStore, eventStore usw.Controller: Sie sind an eine Reihe verwandter API-Aufrufe gebunden, z. eventsController ist dafür verantwortlich, Ereignisse oder ein bestimmtes Ereignis abzurufen oder ein neues Ereignis usw. zu erstellen. Sie leiten die Antwort an andere weiterstores zum späteren Abrufen. Sie bewahren die Antwort nicht mehr auf, nachdem sie an die Geschäfte gesendet wurde.z.B. eventsController, userSearchController usw.Ansichten: Sie sind an eine bestimmte Sichtweise gebunden. Im Allgemeinen kann meine Anwendung mehrere Ansichten an verschiedenen Stellen haben, z.latestEventsView auf dem Dashboard zusätzlich zu einer separaten Ereignisseite.Vorlagen: sind was sie sind.

Sehr oft müssen meine Vorlagen direkt an die Stores gebunden werden (z.peopleView möchte alle Personen im individualStore in einer Liste auflisten (sortiert nach einer bestimmten Reihenfolge).

Und manchmal binden sie an eine berechnete Eigenschaft

<code>alivePeople: function () { ... }.property('App.individualStore.content.@each'),
</code>

Die verschiedenen Filter- und Sortieroptionen, die in der Ansicht ausgewählt wurden, sollten unterschiedliche Listen aus dem Geschäft zurückgeben. Sie können meine letzte Frage an sehenWas ist der richtige Weg, um zwischen verschiedenen Filteroptionen zu wechseln?

Wer sollte diese Filterung durchführen, die Ansicht selbst oder die Geschäfte?

Ist diese Art der Bindung über mehrere Ebenen in Ordnung oder ein Codegeruch? Ist die Trennung der Bedenken gut oder fehle ich etwas? Sollten die Controller hier nicht mehr tun? Sollten meine Ansichten direkt an Geschäfte gebunden sein?

Gibt es einen speziellen MVC-Fall, der meinen Anforderungen besser entspricht?

Update 17. April 2012 Meine Forschung geht weiter, insbesondere vonhttp://vimeo.com/user7276077/videos undhttp://jzajpt.github.com/2012/01/17/emberjs-app-architecture.html undhttp://jzajpt.github.com/2012/01/24/emberjs-app-architecture-data.html

Einige Probleme mit meinem Design, die ich herausgefunden habe, sind:

Controller, die Anfragen stellen (Stores oder Models oder etwas anderes sollten es tun, nicht Controller)Zustandsdiagramme fehlen - sie sind wichtig für View-Controller-Interaktionen (nach einiger Zeit stellen Sie fest, dass Ihre Interaktionen nicht mehr einfach sind)

Dies ist ein gutes Beispiel für aktuelle Zustandsdiagramme:https://github.com/DominikGuzei/ember-routing-statechart-example

UPDATE 9. JANUAR 2013

Ja, es ist schon lange her, aber diese Frage wird in letzter Zeit immer häufiger gestellt, und deshalb möchte ich sie gerne bearbeiten, damit die Leute ein Gefühl dafür bekommen.

Embers Landschaft hat sich sehr verändert, seitdem diese und die neue Frage gestellt wurdenFührer sind stark verbessert. EmberJS hat sich Konventionen ausgedacht (wie Rails) und die MVC ist jetzt viel klarer definiert.

Wer immer noch verwirrt ist, sollte alle Anleitungen lesen und sich einige Videos ansehen:Seattle Ember.js Meetup

Im Moment aktualisiere ich meine Anwendung aufEmber.js 1.0.0-pre2.