Click here to Skip to main content
11,640,910 members (59,219 online)
Click here to Skip to main content

Munq IOC Container – Creating a Thread Local Storage Lifetime Manager

, 24 May 2010 CPOL 11.3K 7
Rate this:
Please Sign up or sign in to vote.
Munq IOC Container – Creating a Thread Local Storage Lifetime Manager

Table of Contents

  • “You have mail”
  • What is a Lifetime Manager?
  • What Lifetime Managers are available?
  • Examining an Existing Lifetime Manager
  • Creating a new Lifetime Manager
  • Conclusion

“You Have Mail”

Just as I was starting on my second article about Using Munq IocContainer V2 in ASP.NET MVC2 Applications, I received the following email.

Miro Bartanus has posted a new comment at "[Article]: Introduction to Munq IOC Container for ASP.NET":

Hi Matthew, Munq is very nice, I am just wondering if it supports TLS as a Lifetime, I will check sources later today, but you maid (might) know, or that should not be too difficult to implement...

and I thought, “What a great idea.” I’d already planned an article on creating a Lifetime Manager, but wasn’t sure of the type. A ThreadLocalStorageLifetimeManager is relatively easy, and it's something I need to solve some of my own programming issues now that I’ve started to use the Parallel Programming library in .NET 4.

What is a Lifetime Manager?

A LifetimeManager controls the reuse of instances when the IOC Container is asked to Resolve a type. The LifetimeManager used when resolving can be specified as a default on the Container by calling the UsesDefaultLifetimeManagerOf method. The following example sets the default LifetimeManager to the RequestLifetimeManger, causing instances to be reused for the duration of each HTTP Request.

// create the container.  Only done once in Application_Start
IIocContainer iocContainer = new Container();

// create a lifetime manager to use as default
ILifetimeManager lifetimeManager = new LifetimeManagers.RequestLifetime();

// set the default lifetime manager
iocContainer.UsesDefaultLifetimeManagerOf(lifetimeManager);

Alternately, you can call the WithLifetimeManager method on the IRegistration instance returned from the RegisterXXX call. The following example registers two services and causes the same instance to always be returned from the container, effectively making them singletons.

// create the container.  Only done once in Application_Start
IIocContainer iocContainer = new Container();

// create a Container lifetime manager to use for 'singleton' services
// only one instance will be created and reused for each resolve request.
ILifetimeManager containerLifetimeManager = new LifetimeManagers.ContainerLifetime();

iocContainer.Register<IMembershipService>( ioc => 
	new AccountMembershipService(Membership.Provider))
            .WithLifetimeManager(containerLifetimeManager);

iocContainer.Register<IFormsAuthenticationService>
	(ioc => new FormsAuthenticationService())
            .WithLifetimeManager(containerLifetimeManager);

What Lifetime Managers are Available?

Munq has a number of LifetimeManagers included with the version 2.0 release. These are described below. I will be adding the ThreadLocalStorageLifetimeManger to a future point release.

Warning: If you used the RegisterInstance method, then the same instance will be returned regardless of which lifetime manager is used.

AlwaysNewLifetime
This lifetime manager’s behaviour is to always return a new instance when the Resolve method is called by executing the factory method. This is the default behaviour.
ContainerLifetime
This lifetime manager’s behaviour is to always return the same instance when the Resolve method is called by executing the factory method. The instance is cached in the container itself.
SessionLifetime
This lifetime manager’s behaviour is to always return an attempt to retrieve the instance from Session when the Resolve method is called. If the instance does not exist in Session, then a new instance is created by executing the factory method, and storing it in the Session.
RequestLifetime
This lifetime manager’s behaviour is to always return an attempt to retrieve the instance from Request.Items when the Resolve method is called. If the instance does not exist in Request.Items, then a new instance is created by executing the factory method, and storing it in the Request.Items.
CachedLifetime
This lifetime manager’s behaviour is to always return an attempt to retrieve the instance from Cache when the Resolve method is called. If the instance does not exist in Cache, then a new instance is created by executing the factory method, and storing it in the Cache. CacheDependencies and Sliding or Absolute Timeouts can be applied to the CachedLifetimeManager.

Examining an Existing Lifetime Manager

A Lifetime Manager implements the ILifetimeManager interface and its two methods. The first method, GetInstance, gets the requested instance from the LifetimeManager’s cache, or creates an new instance if there is no cached instance. The second method, InvalidateInstanceCache, removes any previously created and cached instance, forcing a new instance to be created on the next resolve request.

public interface ILifetimeManager
{
    object GetInstance(IInstanceCreator creator);
    void InvalidateInstanceCache(IRegistration registration);
}

Below is the code for the RequestLifetimeManager. In the GetInstance method, the code attempts to retrieve an instance from the HttpContext.Request.Items collection using the Key property of the IInstanceCreator, creator, passed in. If the instance does not exist, the IInstanceCreator CreateInstance method is called, specifying that the instance is not to be cached in the container. This returns a new instance of the required type, and it is stored in the HttpContext.Request.Items collection for future reuse.

The InvalidateInstanceCache method just removes any stored instance, forcing the creation of a new instance on the next resolve request.

The other code is to support testing and can be ignored.

using System.Web;

namespace Munq.LifetimeManagers
{
    public class RequestLifetime : ILifetimeManager
    {
        private HttpContextBase testContext;

         /// <span class="code-SummaryComment"><summary>
</span>

Creating a new Lifetime Manager

Now you have enough knowledge to create a new LifetimeManager. The basic steps are:

  1. Create a class derived from ILifetimeManger
  2. Implement the two methods

I am going to create these in the source for Munq.IocContainer because I think this a great addition, but you could create a new project and include a reference to Munq.Interfaces. Then if you needed your custom LifetimeManager, you would reference your DLL.

The class needs a thread local dictionary or hashtable to store the instances. Otherwise, the code is just about the same as the code for RequestLifetimeManager. The full code is:

>using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;

namespace Munq.LifetimeManagers
{
    /// <span class="code-SummaryComment"><summary>
</span>

Unit tests for this are:

>using Munq.LifetimeManagers;
using Microsoft.VisualStudio.TestTools.UnitTesting;
using System;
using Munq;
using System.Web;
using MvcFakes;
using Munq.FluentTest;
using System.Threading.Tasks;

namespace Munq.Test
{      
    /// <span class="code-SummaryComment"><summary>
</span>

Conclusion

Adding your own custom Lifetime Manager is simple, and allows you to support any custom data storage, caching, sessions, etc. that you may have written or use. How about an AppFabricLifetimeManager?

Please watch for future articles.

License

This article, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)

Share

About the Author

Matthew Dennis
Software Developer (Senior) CodeProject
Canada Canada
Matthew works on improving the performance and experience of the Code Project site for users, clients, and administrators.

Matthew has more years of software develeopment, QA and architecture experience under his belt than he likes to admit. He gradutated for the University of Waterloo with a B.Sc. in Electrical Engineering. He started out developing micro-processor based hardware and software including compilers and operating systems.
His current focus is on .NET web development including jQuery, Webforms, MVC, AJAX, and patterns and practices for creating better websites.
He is the author of the Munq IOC, the fastest ASP.NET focused IOC Container.
His non-programming passions include golf, pool, curling, reading and building stuff for the house.

You may also be interested in...

Comments and Discussions

 
QuestionThanks For good article Pin
Ram Balak Sharma25-Jul-12 1:19
memberRam Balak Sharma25-Jul-12 1:19 

General General    News News    Suggestion Suggestion    Question Question    Bug Bug    Answer Answer    Joke Joke    Rant Rant    Admin Admin   

Use Ctrl+Left/Right to switch messages, Ctrl+Up/Down to switch threads, Ctrl+Shift+Left/Right to switch pages.

| Advertise | Privacy | Terms of Use | Mobile
Web03 | 2.8.150731.1 | Last Updated 24 May 2010
Article Copyright 2010 by Matthew Dennis
Everything else Copyright © CodeProject, 1999-2015
Layout: fixed | fluid