En primer lugar, mi pregunta solo se aplica a las aplicaciones web y tiendo a configurar la mayoría de mis enlaces Ninject con una resolución InRequestScope.Ninject Rebind en el tiempo de ejecución, ¿se puede usar como característica alternar?
Estoy pensando en maneras de conseguir alternar función, y se le ocurrió que tengo es llamar:
kernel.Rebind<IInterface>().To<RealImplementation>().InRequestScope();
mientras que el sitio web está todavía en funcionamiento, y el interruptor ha sido flicked. Pues si yo decido desactivar la función podría llamar
kernel.Rebind<IInterface>().To<EmptyImplementation>().InRequestScope();
Mi pensamiento es que el InRequestScope protegería cualquier "en curso" peticiones de código, pero permitirá nuevas solicitudes para obtener la nueva característica conmutado.
¿Alguien sabe por experiencia (o un conocimiento más profundo de Ninject) si es probable que esto funcione, o si me va a causar más problemas? He examinado superficialmente MEF, así que será mi próximo puerto de escala si Ninject no es la mejor herramienta para el trabajo en este caso.
hmmmm interesante. Entonces, si te sigo correctamente, tu idea es sustituir rebind por .ToMethod en donde el código pueda validar una condición por llamada (por ejemplo, se establece la bandera). No creo que esto provoque ningún gasto de rendimiento ya que mi suposición es que Ninject se une por llamada en lugar de almacenar en caché un resultado de retorno. En este caso, estaría revisando el almacenamiento azul para que haya una penalización de verificación, pero esto podría guardarse en caché durante x cantidad de tiempo aceptable. – Dylan
@Dylan Semántica menos trivial como esa podría probablemente expresarse en un [Proveedor] (https://github.com/ninject/ninject/wiki/Providers%2C-Factory-Methods-and-the-Activation-Context) (el caché probablemente podría ser administrado a través de DI y solo ser código). Por otra parte, un método estático directo podría encajar en la factura ... –