comportamento Singleton-come con Dependency Injection

Dopo aver fatto qualche ricerca su MEF mi sono imbattuto nel CreationPolicy.Shared proprietà che secondo MSDN:comportamento Singleton-come con Dependency Injection

Specifica che una singola istanza condivisa delle associate ComposablePart sarà creato da CompositionContainer e condiviso da da tutti i richiedenti.

Suoni buoni fintanto che mi assicuro sempre che uno e un solo container accedano sempre alla classe che esporto con questo criterio. Quindi, come faccio a garantire che solo un container acceda al mio tipo esportato? Ecco il mio scenario:

Ho un servizio di Windows che deve entrare in una classe simile a un singleton per alcuni dati in memoria. I dati non sono persistenti quindi voglio che vengano creati di recente ogni volta che il servizio si avvia ma non serve a niente una volta che il servizio è stato interrotto. Più thread nel mio servizio dovranno leggere e scrivere su questo oggetto in modo thread-safe, quindi il mio piano iniziale era di ereditare da ConcurrentDictionary per garantire operazioni thread-safe contro di esso.

I thread che verranno toccati in questa classe erediteranno tutti da una singola classe di base astratta, quindi c'è un modo per far sì che questa classe (e solo questa classe) la importi da MEF e abbia questo lavoro nel modo che voglio?

grazie per eventuali suggerimenti che potete avere, io sono newish al MEF così sto ancora imparando i trucchi

fonte

2012-06-15 snappymcsnap

ho usato Ninject con la sua modalità "as singleton" per un binding di grande effetto. Basta fare attenzione a mantenere tutto ciò che è MEF fornendo in questo modo thread-safe (nessun effetto collaterale statico o divertente). – bluevector

@jonnyGold Grazie, non ho mai usato Ninject in precedenza ... non funziona su MEF o è il suo unico framework DI? – snappymcsnap

È la sua struttura. Puoi prenderlo tramite nuget e ci sono specializzazioni per MVC e WCF. La cosa che preferisco è che i binding sono dichiarati in codice, quindi non si può commettere un errore di corrispondenza del tipo. O un refuso, del resto. Inoltre, i binding contestuali sono davvero potenti. – bluevector

Se deve assolutamente essere un Singleton tra i diversi contenitori, è possibile utilizzare un costruttore privato e esporre una proprietà statica Instance, come se fosse un singleton "classico" non gestito dal contenitore. Poi nella radice composizione, utilizzare ComposeExportedValue registrarlo con il contenitore:

container.ComposeExportedValue(MySingleton.Instance);

fonte

2012-06-15 19:30:52

non proprio, se possibile vorrei esporlo solo ad un singolo contenitore e il framework MEF assicurerà che sia un singleton di default. Tuttavia, se ciò non è possibile, non vedo alcun vantaggio nell'utilizzare MEF per questo in primo luogo – snappymcsnap

Non sono sicuro di aver capito esattamente cosa stai chiedendo. Dovresti assicurarti che esista solo un container. Quindi "CreationPolicy.Shared" darà come risultato un singleton. Stai pensando di creare più contenitori? Perché quello sarebbe atipico. –

Si può sempre utilizzare il tipo pigro poiché blocca altri thread come descritto in questo post del blog: http://geekswithblogs.net/BlackRabbitCoder/archive/2010/05/19/c-system.lazylttgt-and-the-singleton-design-pattern.aspx

fonte

2012-06-15 19:47:46 kappasims

comportamento Singleton-come con Dependency Injection

risposta

Problemi correlati