When to use Singleton vs Transient vs Request using Ninject and MongoDB

Question

I\'m not quite sure when I should use SingletonScope() vs TransientScope() vs RequestScope() when I do my binding in my global.cs file.

I have for example my call to

Answer 1

From deleted question as requested by @shankbond above

---

The Disposal is not necessarily performed synchronously on your main request thread as one might assume.

You probably want to stash a Block and then Dispose() it at an appropriate phase in your request (how are you going to handle exceptions?)

Have a look in the Ninject Tests for more examples (seriously, go look - they're short and clear and I didnt regret it when I listened the 3rd time I was told to!)

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

Answer 2

In general in a web app, you want state to be request scope as much as possible.

Only in the case of very low level optimisations are you ever likely to run into a case where its appropriate to create singleton objects (and the chances even then are that you'll pull such caching / sharing logic out into another class which gets pulled in as a dependency on your other [request scope] objects and make that singleton scope). Remember that a singleton in the context of a web app means multiple threads using the same objects. This is rarely good news.

On the same basis, transient scope is the most straightforward default (and that's why Ninject 2 makes it so) - request scope should only come into the equation when something needs to be shared for performance reasons, etc. (or because that's simply the context of the sharing [as mentioned in the other answer]).

Answer 3

I guess the answer would depend on whether your MongoSession represents a unit of work or not. Most database related classes that I've worked with (mostly in the context of ORM, such as NHibernate or EF4) revolve around a context, entities, and tracked state that represent a unit of work. A unit of work should never be kept around longer than the length of time required to perform the given unit of work, after which the unit should be committed or rolled back. That would mean you should use RequestScope.

If your MongoSession is not a unit of work, you could keep it around for the lifetime of an MVC session, in which case SessionScope would then be appropriate.