Comprensione della relazione tra controllori e percorsi in Ember

Question

Ho un po 'di problemi a comprendere la relazione concettuale tra controllori e percorsi in un'applicazione Ember.

Ho iniziato il percorso di un semplice spike test per valutare Ember, e più approfondisco, più vedo che i miei percorsi si riempiono di quello che avrei dovuto passare per il controller responsabilità, ad esempio azioni, cablaggio di modelli e infine invio a una vista per il rendering di un modello.

I controller sono tutti vuoti e sembrano essere solo un segnaposto per alcuni requisiti di mappatura automatica.

Mi manca una cosa fondamentale qui - provenendo da una prospettiva Rails, e applicando (forse erroneamente) la "via delle rotaie" a Ember mi aspettavo che i miei percorsi definissero stati rappresentati da URL, che verrebbero mappati su un controller "azione".

Qualsiasi suggerimento sarebbe molto apprezzato.

Answer 1

Mentre le classi del modello gestiscono gli oggetti e il loro stato, il controller gestisce lo stato dell'applicazione stessa.

Un caso di utilizzo molto semplice potrebbe essere quello di avere due stati per un modulo: readonlyMode e modifyMode. Questo chiaramente non appartiene al modello in cui sono definiti gli oggetti reali. È solo uno stato della tua applicazione.

Se il controller dice che lo stato è di sola lettura, la vista renderà tutti i campi di input disabilitati. Il contrario va per il modifyMode.

Ma sono d'accordo che non è sempre facile decidere dove metterlo. Alla fine, MVC parla di concetti. Dovendo metterlo in una sorta di regole, direi:

• tutto ciò che rappresenta i dati persistenti (memorizzati in una sorta di memoria/DB) è solitamente parte del modello.
• tutto ciò che aiuta a rendere lo stato stateful => controller.