Cuándo utilizar Singleton vs Transient vs Request utilizando Ninject y MongoDB

Question

No estoy muy seguro de cuándo debería usar SingletonScope() frente a TransientScope() frente a RequestScope() cuando hago mi enlace en mi archivo global.cs.

tengo por ejemplo, mi llamada a MongoSession (usando norma y el proyecto mvcStarter http://mvcstarter.codeplex.com/), que se establece en SingletonScope pero he creado un repositorio que utilizan este objeto MongoSession para realizar llamadas a Mongo más fácil, por ejemplo, tengo un NewsRepository cuales usa MongoSession para buscar mis Noticias de los datos. Como ejemplo, tengo una llamada que recupera Noticias que tiene DisplayOnHome establecido en verdadero y recibe la última fecha de CreationDate. ¿Debería dicho repositorio ser SingletonScope o RequestScope sería más apropiado?

¿Cuándo debería usar cada uno de ellos y por qué?

Answer 1

En general, en una aplicación web, desea que el estado solicite el alcance tanto como sea posible.

Solo en el caso de optimizaciones de muy bajo nivel es probable que se encuentre con un caso en el que es apropiado crear objetos singleton (y las posibilidades son que tire de esa lógica de almacenamiento en caché/compartir en otra clase que se obtiene como una dependencia de sus otros objetos [ámbito de solicitud] y hacer ese alcance de singleton). Recuerde que un singleton en el contexto de una aplicación web significa múltiples hilos usando los mismos objetos. Rara vez son buenas noticias. De la misma manera, el alcance transitorio es el predeterminado más directo (y es por eso que Ninject 2 lo hace): el alcance de la solicitud solo debe incluirse cuando se debe compartir algo por motivos de rendimiento, etc. ese es simplemente el contexto del intercambio [como se menciona en la otra respuesta]).

Answer 2

Supongo que la respuesta dependerá de si su MongoSession representa una unidad de trabajo o no. La mayoría de las clases relacionadas con bases de datos con las que he trabajado (principalmente en el contexto de ORM, como NHibernate o EF4) giran en torno a un contexto, entidades y estado de seguimiento que representan una unidad de trabajo . Una unidad de trabajo nunca debe mantenerse durante más tiempo que el tiempo requerido para realizar la unidad de trabajo determinada, después de lo cual la unidad debe comprometerse o revertirse. Eso significa que debe usar RequestScope.

Si su MongoSession es no una unidad de trabajo, usted podría mantenerlo en torno a la vida de una sesión de MVC, en cuyo caso SessionScope entonces sería apropiado.

Answer 3

De la pregunta eliminado conforme a lo solicitado por @shankbond anterior

---

El Dispos al no necesariamente se lleva a cabo de forma sincronizada en el hilo principal solicitud como uno podría suponer.

es probable que desee para guardar un Block y luego Dispose() que en una fase apropiada en su solicitud (¿cómo se va a manejar excepciones?)

Tener una mirada en las Pruebas ninject para más ejemplos (en serio, vaya ven - son cortas y claras y yo no lo lamentamos cuando escuché la tercera vez que me dijeron a)

ver http://kohari.org/2009/03/06/cache-and-collect-lifecycle-management-in-ninject-20/