¿Debo usar InSingletonScope al vincular MembershipProvider en NInject?

Question

Soy bastante nuevo en el enlace NInject, y esto es lo que describe NInject.

• TransientBehavior : se creará una nueva instancia del tipo cada vez que se solicite.
• SingletonBehavior : solo se creará una única instancia del tipo y se devolverá la misma instancia para cada solicitud posterior.
• OnePerThreadBehavior : se creará una instancia del tipo por hilo.
• OnePerRequestBehavior : se creará una instancia del tipo por solicitud web y se destruirá cuando finalice la solicitud.

Si deseo vincular MembershipProvider a SqlMembershipProvider, ¿debo usar SingletonBehavior ya que solo necesito un proveedor de membresía sql?

Answer 1

ASP.Net ya proporciona una instancia estática del proveedor de membresía actual a través de la clase estática Membresía y su propiedad estática Proveedor . El enlace probablemente estaría en su método Application_Start y se vería así:

Bind<MembershipProvider>()
  .ToMethod(ctx => Membership.Provider);

Nuevamente, debido a que Membership.Provider es estático, ya es algo así como un singleton, por lo que el comportamiento que intenta aplicar realmente no importa tanto.

Al no especificar ningún comportamiento en el fragmento anterior, Ninject pasará de forma predeterminada a un comportamiento transitorio. En este tipo de enlace, creo que eso equivaldrá a llamar a la lambda que devuelve Membership.Provider cada vez que necesita inyectar un tipo MembershipProvider .

Supongo que podría haber un argumento para especificar explícitamente un comportamiento singleton como Ninject probablemente & "; caché &"; el valor devuelto por la lambda la primera vez que necesita inyectar un MembershipProvider , en efecto ahorrando la sobrecarga de ejecutar la lambda. No estoy 100% seguro de que así sea como funcionaría Ninject en esta situación, pero parece razonable que lo haga.

Dicho todo esto, mi preferencia personal sería usar OnePerRequestBehavior , de esta manera sé que Ninject llamará a mi lambda una vez por cada solicitud. No estoy seguro de que sea necesario, pero me gusta la idea de obtener el proveedor de Membership.Provider una vez cada solicitud, ya que supongo que no puede hacer suposiciones sobre cómo o cuándo Membership.Provider get's set, aunque probablemente puedas descubrir si cavas lo suficiente con Reflector.

Bind<MembershipProvider>()
  .ToMethod(ctx => Membership.Provider)
  .Using<OnePerRequestBehavior>();

Buena suerte. ¡Lamento que tu pregunta haya estado aquí tanto tiempo!