Pattern per persistere di $ scope tra route

Question

Trovo che quasi sempre si vogliano persistere gli scope attraverso le route change, e per questo motivo ho scoperto che ho praticamente smesso di usare i controller, per qualcosa di diverso dall'inoltro di tutto a un servizio . I miei Controller tutti finiscono per guardare qualcosa di simile:

app.factory('CtrlAService', function() { 
    return { 
     scope: {}, 
    }; 
}); 

function CtrlA($scope, CtrlAService) { 
    $scope.data = CtrlAService.scope; 

} 

Vale a dire, tutto ciò che il mio controller non c'è da associare una variabile a una variabile di servizio, e, a parte una funzione di legame o due - io non uso controller per qualsiasi cosa.

Questo approccio è corretto, e in caso contrario, quale è un modo migliore per farlo?

Ho fatto un esempio di applicazione qui: http://jsfiddle.net/Wc22k/1/

Answer 1

Penso che questa è generalmente una sorta di vero se si dispone di un data applicazione pesante. Più hai bisogno di funzionalità per le viste più ti ritrovi nei tuoi controller. Ad esempio sto utilizzando google-maps e ng-grid all'interno di un'applicazione abbastanza estensivamente, quindi tutti i miei controller contengono tutta la configurazione (a volte funzioni per la visualizzazione di etichette, ecc.) All'interno dei controller. Anche il codice google-maps che ho trovato e che ho modificato (MIT Licensed) ha un oggetto JavaScript piuttosto complesso che racchiude il codice di google maps e un controller per la direttiva.

Versione così breve, sì in un'applicazione di dati pesanti la maggior parte del codice finisce nei servizi e i controllori stanno semplicemente collegando la vista ad alcuni dati di un servizio, in altri casi no. Vedo cosa stai dicendo sull'ottica persistente, ma penso che sia meglio lasciare tutta la logica necessaria per la vista nel controller (vedo questo come modello di visualizzazioni rispetto al modello di dati nel servizio). Mantiene semplicemente una chiara separazione di ciò che sta accadendo dove e cosa sta influenzando cosa. Per esempio, se ho bisogno di mantenere un dato tra alcune viste lo memorizzo nel servizio (ho considerato di usare un "valore" invece dato che è più semanticamente e funzionalmente appropriato ma semplicemente non ho avuto il tempo di farlo fattore).