EmberJS: buona separazione delle preoccupazioni per modelli, negozi, controllori, viste in un'applicazione piuttosto complessa?

Question

Sto facendo un'applicazione emberjs abbastanza complessa e la leggo a un backend di API.

Le chiamate API non sono in genere legate a nessun modello particolare, ma possono restituire oggetti di vario tipo in diverse sezioni della risposta, ad es. una chiamata all'API di eventi restituirebbe gli eventi, ma restituirà anche le risorse multimediali e le persone coinvolte in quegli eventi.

Ho appena iniziato il progetto e vorrei ottenere alcune indicazioni esperte sul modo migliore per separare le preoccupazioni per avere una base di codice gestibile e pulita.

Il modo in cui mi sto avvicinando questo è:

• modelle: in sostanza, di gestire i record con i loro campi, e altre proprietà calcolati. Tuttavia, i modelli non sono responsabili per le richieste.
  • ad es. Individuo, evento, foto, posta ecc.
• Negozi: Sono essenzialmente cache. Ad esempio, un eventStore memorizzerebbe tutti gli eventi ricevuti dal server fino ad ora (da eventuali richieste diverse) in un array e anche in un hash di eventi indicizzati da id.
  • ad es. individualStore, eventStore ecc
• Controllori: legano ad una serie di chiamate API correlate, per esempio eventController sarebbe responsabile per il recupero di eventi o un particolare evento, o la creazione di un nuovo evento, ecc. Avrebbero "indirizzato" la risposta a diversi stores per il successivo recupero. Non mantengono la risposta una volta che è stata inviata ai negozi.
  • ad es. eventsController, userSearchController ecc
• Visualizzazioni: Essi sono legati a un particolare punto di vista. In generale, la mia applicazione può avere diverse visualizzazioni in luoghi diversi, ad es. latestEventsView sulla Dashboard oltre ad avere una pagina eventi separata.
• Modelli: sono quello che sono.

Molto spesso, i miei modelli richiedono di essere vincolato direttamente ai punti vendita (ad esempio peopleView vuole elencare tutti gli individui nella individualStore in un elenco, in ordine di qualche ordine).

E, a volte, si legano a una proprietà calcolata

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

I vari filtraggio e di ordinamento 'prescelto' nella vista, dovrebbe restituire liste diverse dal negozio. Puoi vedere la mia ultima domanda al what is the right emberjs way to switch between various filtering options?

Chi dovrebbe fare questo filtraggio, la vista di se stessi o dei negozi?

Questo tipo di collegamento tra i livelli è corretto o un odore di codice? La separazione delle preoccupazioni è buona o mi manca qualcosa? I controllori non dovrebbero fare qualcosa di più qui? Le mie opinioni dovrebbero legarsi direttamente ai negozi?

Qualsiasi caso speciale particolare di MVC più adatto alle mie esigenze?

aggiornamento 17 Aprile 2012 La mia ricerca va avanti, in particolare da http://vimeo.com/user7276077/videos e http://jzajpt.github.com/2012/01/17/emberjs-app-architecture.html e http://jzajpt.github.com/2012/01/24/emberjs-app-architecture-data.html

Alcuni problemi con il mio progetto che ho capito sono:

• controllori che fanno richieste (negozi o modelli o qualcos'altro dovrebbe farlo, non controller)
• mancano gli stereotipi - sono importanti per le interazioni del controller di visualizzazione (Dopo qualche tempo ti rendi conto le interazioni non sono più semplici)

Questo è un buon esempio di diagrammi di stato in azione: https://github.com/DominikGuzei/ember-routing-statechart-example

UPDATE 9 Gennaio 2013

Sì, è stato a lungo, ma ultimamente questa domanda sta ricevendo molte visualizzazioni, ed è per questo che mi piacerebbe modificarlo in modo che le persone possano avere un senso.

Il panorama di Ember è molto cambiato da quando è stata inquadrata questa domanda e il nuovo guides è stato migliorato molto. EmberJS ha escogitato convenzioni (come Rails) e MVC è ora molto più definito.

Chiunque ancora confuso dovrebbe leggere tutte le guide, e guardare alcuni video: Seattle Ember.js Meetup

Al momento, sto aggiornando la mia domanda di Ember.js 1.0.0-pre2.

Answer 1

• si dovrebbe pensare della vostra applicazione in termini di stati. Date un'occhiata a this

• Inizialmente, solo un percorso e un modello sono necessari per descrivere qualcosa e, infine, visualizzarla nel browser, questo è ciò che il nuovo API di Emberjs cerca di far rispettare. Man mano che le tue esigenze ottengono più informazioni su puoi creare una vista, un controller o un oggetto. Ogni tuttavia risponde a una necessità specifica.

• consideri una vista se è necessario gestire tutti gli eventi del tuo browser o avvolgere
  qualsiasi 3rd party JavaScript lib si sta utilizzando per l'animazione, lo styling ..

• consideri un oggetto se è necessario acquisire dominio specifico
  informazioni, molto probabilmente imitano le informazioni di back-end.

• Un controller è semplicemente un proxy per l'oggetto dominio e può incapsulare la logica che non si riferisce necessariamente all'oggetto.

Questo è tutto quello che serve. Se impari come progettare la tua applicazione in termini di stati, il resto cadrà nel posto giusto, a patto che tu stia usando l'ultima API, facendo rispettare le regole che ho menzionato in precedenza.

Answer 2

Vedi anche questo http://addyosmani.com/largescalejavascript/ Non si tratta di EmberJs in particolare, ma è un ottimo articolo che ti dà un'idea di come scrivere applicazioni javascript di larga scala.

Answer 3

Dal rilascio di Ember 1.0.0-pre4 con la nuova implementazione del router ho visto due buoni riferimenti che descrivono una struttura di app EmberJS standardizzata.

Chi ha familiarità con Rails lo troverebbe abbastanza familiare.

https://github.com/trek/ember-todos-with-build-tools-tests-and-other-modern-conveniences

http://reefpoints.dockyard.com/ember/2013/01/07/building-an-ember-app-with-rails-api-part-1.html

Il progetto brace-rail a https://github.com/emberjs/ember-rails include un generatore di apparati per la creazione di una struttura di directory applicativa EmberJS che è essenzialmente la stessa come la struttura descritta nelle due link sopra.

Le guide di EmberJS ora descrivono anche la nuova struttura di routing.http://emberjs.com/guides/

AGGIORNAMENTO 21/08/2013

Se si utilizza Rails poi la brace-rails gemma è grande. L'ho usato con molto successo. Ci sono due sforzi all'interno della comunità di ember per aiutare nella fornitura di un layout di applicazione di una brace standardizzata. A quanto pare stanno per essere fuse ma per ora il check-out:

https://github.com/rpflorence/ember-tools

https://github.com/stefanpenner/ember-app-kit