2012-09-21 3 views
5

In primo luogo, la mia domanda si applica solo alle app Web e tendo ad impostare la maggior parte delle associazioni Ninject con una risoluzione InRequestScope.Ninject Rebind in fase di runtime, può essere utilizzato come funzionalità?

sto pensando di modi per ottenere funzionalità di commutazione, e ha pensato che ho è quello di chiamare:

kernel.Rebind<IInterface>().To<RealImplementation>().InRequestScope(); 

mentre il sito è ancora attivo e funzionante, e l'interruttore è stato un colpetto. Se dunque io decido di disattivare la funzione Potrei chiamare

kernel.Rebind<IInterface>().To<EmptyImplementation>().InRequestScope(); 

Il mio pensiero è che l'InRequestScope avrebbe proteggere eventuali "in progress" richieste di codice, ma consentirà nuove richieste per ottenere la funzione di recente commutato.

Qualcuno sa per esperienza (o una più profonda comprensione di Ninject) se è probabile che funzioni, o se per me causerà più problemi. Ho guardato superficialmente al MEF, quindi questo sarà il mio prossimo punto di contatto se Ninject non è lo strumento migliore per il lavoro in questo caso.

risposta

0

Una potenziale fonte di problemi è che, mentre il Kernel è sicuro per i thread, è necessario eseguire un semplice passaggio di un singolo switch o si è in una gara per ottenere tutto come un'azione atomica per le richieste in volo . (Questo è in linea di principio, non ho rivisto il codice con questa domanda in mente).

Detto questo, non viene in mente nulla che possa causare direttamente un problema.

Ma anche se può avere senso se si può soddisfare se stessi e/o ottenere un forte garanzia sufficiente in base a qualcuno che ha valutato il codice di base per le condizioni di gara relativi a questo tipo di utilizzo, questa non è una pratica diffusa I' Ho sentito fuori. In effetti, il design di AutoFac è tale che tu costruisci una Factory immutabile da un input di configurazione, escludendo in particolare questo tipo di cose. Il mio istinto sarebbe quello di deviare da un tale approccio per quella ragione.

Avete considerato l'utilizzo di .ToMethod(ctx=> return /* Toggle-based creation*/)? (Ovviamente non afferma le cose direttamente come fa Rebind). A seconda del tuo impl reale (e della complessità dei tuoi attacchi e della natura del sistema di leve) questo può avere senso.

+0

hmmmm interessante. Quindi, se ti seguo correttamente, la tua idea è di sostituire rebind per .ToMethod in cui il codice potrebbe convalidare una condizione per ogni chiamata (ad esempio il flag set). Non penso che ciò causerebbe alcun sovraccarico di prestazioni poiché la mia ipotesi è che Ninject si lega per chiamata piuttosto che memorizzare un risultato di ritorno nella cache. In questo caso controllerei la memoria blu in modo che ci fosse una penalità di controllo, ma questa potrebbe essere memorizzata nella cache per x quantità di tempo accettabile. – Dylan

+0

@Dylan Semantica meno banale come quella potrebbe probabilmente essere espressa in un [Provider] (https://github.com/ninject/ninject/wiki/Providers%2C-Factory-Methods-and-the-Activation-Context) (la cache potrebbe probabilmente essere gestita tramite DI e solo essere codice). Poi di nuovo, un semplice metodo statico potrebbe adattarsi al conto ... –