Ninject, MVC, and Session Scope: Reasonable Practice?

Question

I am creating an MVC3 application with the Entity Framework, where almost all actions are allowed only to authorized users. Therefore, I often have to refer to a member object. I experimented with various ways of caching a member, and came up with an approach that is pretty fast. But I would like to get advice / point of view on the risks / disadvantages of what I do.

I defined a factory class to retrieve a Member instance that is "registered" with Ninject, so I can use it wherever I need it. Linking to Ninject is a “session” (I will explain this in a moment). The factory method first checks the session to see if it contains a previously created Member instance. If the session does not work, the procedure creates an instance from the base database through EF, storing the value in the session and also returning it.

Since some calls to the Member instance are EF calls, I had to ensure that the context of the EF object was also in the session area (I learned a difficult way to call EF routines against the Member instance that was originally created in another context does not work too well). Since the factory and object context are created using Ninject, I had to define the session scope for Ninject.

I found a piece of code for this here that I was able to modify to meet my needs. But this is such a simple fragment that I wonder if there is a reason why the opportunity is not provided “initially” by Ninject (or Ninject MVC). Which makes me wonder, I don’t care what I do.

I understand that there are a number of aspects of storing things in a session that you must program, the main one being the fact that the stored object can "disappear" at any time (i.e. you always need to have a way to recreate it when you receive). But while this adds enough complexity that I would not want to do this for multiple objects, it is not so difficult to do this for a single member object.

In any case, advice and feedback on viewing the Ninject bindings on binding and storing EF objects in a session for an MVC application will be appreciated.

Answer 1

There are several reasons why there is no such area in Ninject itself:

• Implementation makes scaling of the application impossible. Although you can split a session between multiple IIS instances, the data in your session area cannot, because each IIS instance has its own Ninject core.
• This will encourage users to use it on a large scale. But, as a rule, it is not recommended to put data in a session if it is absolutely necessary, because it is cached for a long time and there is no mechanism for its exit from memory before the session expires. This can quickly lead to memory problems. For this reason, session data should be used very carefully.
• The preferred method for session-related data is to add it to the session and add a transient binding to the method that returns the data, or create a new instance if it is not already available. This way, the data is deleted along with the session, and not stored in memory for some extra time until Ninject releases it. In addition, application scaling is supported in this way.

No problem with your implementation of Ninject-wise. But, as I said, you must be very careful about entering data into the session area. I think you should also consider other ways to cache data that allow data to be crowded out before using this approach, for example with NHibernate. I would suggest learning about level 2 caching. If you still decide to use session data, the best way is to put it in the session, rather than having a Ninject session area, since it allows you to scale the application.