È una buona idea registrare viste e visualizzare modelli come singleton in un container IOC?

Question

È una buona idea registrare viste e visualizzare modelli come singleton in un container IOC?

#1 da (2 voti)
#2 da (1 voti)
#3 da (1 voti)

5

Comprendo i vantaggi dell'iniettare le dipendenze negli oggetti, ma non ho trovato molte indicazioni sui tipi di oggetti da iniettare e quando renderli singleton.

Se prendiamo come esempio un'applicazione con i seguenti tipi di oggetti:

Servizi (inclusi repository e servizi aziendali come calcolare il prezzo)
Visualizzazioni
ViewModels

servizi

I servizi di iniezione sono l'esempio tipico dato ed è chiaro che questi non sono registrati come singleton nel contenitore in quanto sono senza stato.

Era l'intenzione originale che solo i servizi dovrebbero essere iniettati dai contenitori?

Views / ViewModels & altri oggetti di stato duraturi

Il modo generale per accedere a un oggetto di lunga durata in più punti è stato quello di utilizzare un registro (o simile), supponendo che non possiamo passarlo come parametro. Ora abbiamo la possibilità di registrare l'oggetto come un singleton in un contenitore e iniettarlo dove necessario.

Non riesco a vedere alcun problema nell'usare il singleton in un approccio contenitore oltre il problema di rimuovere l'oggetto dal contenitore quando termina il suo ciclo di vita (non sono sicuro di quanto sarà facile - Io uso Unity).

Sarebbe interessato a conoscere eventuali problemi che altri possono prevedere.

Per inciso, il framework MVVM Light utilizza un ViewModelLocator piuttosto che iniettare viewmodels.

dependency-injection design-patterns

posta sturdytree 03.02.2013 - 14:13

fonte

3 risposte

Leggi altre domande sui tag dependency-injection design-patterns

Avere un tipo di dati generico per una colonna della tabella del database, è una pratica "buona"? Programmazione in ambiente accademico rispetto all'ambiente industriale [duplicato]

score 2 · Answer 1

Bene, dipende da ciò di cui hai bisogno. Se non avrai mai due o più viste dello stesso tipo, suppongo che sia ok registrarle come singleton.

Ma allora, cosa succede se si dispone di una vista composta da altre due viste (e dai relativi modelli di vista), ad esempio, se si confrontano alcuni dati? Non è possibile utilizzare la stessa istanza, poiché è necessario popolare quelli con dati diversi.

Inoltre, se hai molte viste e un certo tipo di navigazione, in cui ogni vista viene creata quando arrivi ad essa, quelle viste singleton si attardano da qualche parte quando ti allontani da esse. Il contenitore manterrebbe un riferimento e non verrebbero mai raccolti.

MODIFICA: per quanto riguarda il tuo commento, penso che non avresti problemi se la vista fosse stata registrata come singleton. Detto questo, non lo farei. Di solito uso "singleton" per stateless (o statefull, ma dove lo stato non può essere modificato dopo che è stato impostato quando è stato istanziato la prima volta) oggetti come repository o oggetti che devono assolutamente essere istanze singole durante l'intera vita dell'applicazione. In MVVM ci sarebbe un controller che è responsabile della gestione delle viste (per la navigazione). Lascerei le viste loro stesse e i loro modelli di visualizzazione come oggetti normali, anche se all'inizio userò solo uno di essi. Questa è solo la mia preferenza, però.

PS: Non ho esperienza con MVVM Light, ma l'utilizzo del contenitore come servizio di localizzazione è generalmente considerato un anti-modello da molti, poiché si sta introducendo una dipendenza dal contenitore. Le viste e i modelli di vista (e i modelli di dominio) dovrebbero essere il più possibile liberi dai costrutti di "infrastruttura" come il contenitore. Quando il tuo codice arriva al modello di visualizzazione, dovrebbe semplicemente avere tutto ciò di cui ha bisogno, e non cercarlo usando il contenitore.

score 1 · Answer 2

Questo problema si riduce in realtà al ciclo di vita / ambito previsto delle tue istanze.

Ci sarà una singola istanza della tua classe per la durata dell'applicazione? Quindi un "singleton" va bene. Ho citato singleton perché è veramente lo ambito di applicazione a cui si riferisce.

Una buona panoramica di come gli ambiti sono nidificati e l'integrazione delle dipendenze funziona con questo, vedere la introduzione di PicoContainer (I'm non suggerendo di usare PicoContainer, basta leggere l'introduzione per avere una presa su questa roba).

score 1 · Answer 3

Vorrei aggiungere che le nostre visualizzazioni di Vaadin mantengono lo stato sul server, principalmente i controlli che le costituiscono. Se le tue opinioni si trovano in una situazione simile in un ambiente multiutente, non puoi usare singleton. Potresti usare qualcosa di simile, come un Prototipo , per ritagliare nuove istanze da un modello. Puoi riutilizzare le visualizzazioni per lo stesso utente per diverse iterazioni dello stesso flusso di lavoro, per le quali probabilmente utilizzerai peso vivo , o altrimenti dovrai reimpostare lo stato di visualizzazione all'inizio di ogni riutilizzo, che probabilmente non ne vale la pena.

In ogni caso, nascondere i dettagli di un registro ti darà la possibilità di passare da uno all'altro dei due modelli se trovi problemi lungo la strada.