InstancePerLifetimeScope in Modules for Web Projects

[Cecil Phillip]

This might be a crazy question, but...

I have an application that is split up into different projects. One of the projects, lets call it Project D, will be consumed  by a web and a desktop clients. Project D has a module with various registrations in it. Instead of registering my components with InstancePerHttpRequest I want to register them with InstancePerLifetimeScope since I don't want to add Autofac.Integration.Mvc to it. I'm assuming the Mvc Integration takes a dependency on System.Web.

Will InstancePerLifetimeScope properly configure / handle the lifetime like InstancePerHttpRequest  would in the web application? Or would I still need to call InstancePerHttpRequest ?

[Alex Meyer-Gleaves]

Hi Cecil,

Using InstancePerHttpRequest ensures that the service is resolved from the correct lifetime scope at runtime. In the case of MVC this is always the special HTTP request lifetime scope.

When using InstancePerLifetimeScope the service can be resolved in any lifetime scope so you are not able to enforce that a particular lifetime scope is being used. This is not necessarily a problem but it’s something that you need to be aware of. For example, if you created a nested lifetime scope inside the HTTP request, a service registered with InstancePerLifetimeScope would result in a new instance for each lifetime scope (one for the request scope and one for the nested scope).

I think you will be fine if you make sure that your shared project only contains common services that are registered using InstancePerLifetimeScope. The most important thing is that the controllers are always registered with InstancePerHttpRequest so that you definitely only get one instance per request. Any of the controller’s dependencies that are registered with InstancePerLifetimeScope will be resolved from the HTTP request lifetime scope.

Cheers,

Alex.

[Cecil Phillip]

Thanks Alex. Your response definitely helped me get a better grasp of how things would work. Any suggestions on how I may go about unit testing the registrations for web applications?

[Cecil Phillip]

What about if I used  InstancePerMatchingLifetimeScope(<asp.net lifetime session>) instead ?

Would that work any better?

[Alex Meyer-Gleaves]

The thought did cross my mind when I replied earlier, but I wasn't sure about letting an implementation detail of the HTTP request lifetime scope escape out in the desktop world. It would certainly work though, and creating an extension method for this would isolate the use of the special tag to one location. You would also have to make sure that the lifetime scope in the desktop application that the parent services will be resolved from is created using the same tag. Again, you would want to keep the use of the special tag in a single place.

I would probably start with InstancePerHttpRequest for your controllers, and use InstancePerMatchingLifetimeScope for the other shared services. If you don't have complex lifetime management requirements (such as many levels of nested scopes) you will probably be fine. You can always move to using the special tag later if you find it becomes necessary for some reason.

In regards to unit testing the registrations, are you wanting to assert that the correct lifetimes are applied to the services via the registrations, or is the question more about mocking the lifetime scope when no HTTP request is available?

On 6 June 2012 00:07, Cecil Phillip <cecilp...@gmail.com> wrote:

What about if I used  InstancePerMatchingLifetimeScope(<asp.net lifetime session>) instead ?

Would that work any better?

--
You received this message because you are subscribed to the Google Groups "Autofac" group.

To view this discussion on the web visit https://groups.google.com/d/msg/autofac/-/3wF0Ol579ZoJ.

To post to this group, send email to aut...@googlegroups.com.
To unsubscribe from this group, send email to autofac+u...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/autofac?hl=en.

[Cecil Phillip]

At this point, I don't foresee anymore than one nested lifetime being necessary for this project  scope. I read Nick's lifetime primer blog post. Can I use InstancePerMatchingLifetimeScope("httpRequest")  reliably, i.e. assuming the "httpRequest" tag doesn't change. 

On another note, Is it even possible to set the tag used for the ASP.NET integration?

As for testing, your guess was correct. I just want to verify the correct lifetimes to the various services.

[Alex Meyer-Gleaves]

I wouldn't say reliably; I've already changed it for the MVC 4 and Web API integrations. :) That is what was making a little nervous about the implementation details leaking out.

It is not possible to change the tag that is used for the HTTP request lifetime scope.

If you would like to write unit tests for the lifetimes take a look at the Assertions class in the Autofac.Tests project. In particular look at the AssertSharing, AssertLifetime, and AssertOwnership methods. Matching these to the actual registrations can be a little weird though and I usually don't bother to unit test the lifetime of registrations. I'm very careful when adding a registration to consider lifetime management though. ;)

[Cecil Phillip]

Thanks for all your help Alex