Switch to CommonServiceLocator?

[Simone Busoli]

http://www.codeplex.com/CommonServiceLocator

http://codebetter.com/blogs/glenn.block/archive/2008/10/02/iservicelocator-a-step-toward-ioc-container-service-locator-detente.aspx

[Eric Hexter]

I need to dig into this further, but I think we can easily switch the
IocController factory and just replace our internal dependency
resolver interface. It will be really nice if we do not have to
maintain the implementations for each DI framework.!

On Oct 2, 6:14 am, "Simone Busoli" <simone.bus...@gmail.com> wrote:
> http://www.codeplex.com/CommonServiceLocatorhttp://codebetter.com/blogs/glenn.block/archive/2008/10/02/iservicelo...

[Tuna Toksöz]

There are adaptors written for Castle, and some other known DI framework.

--
Tuna Toksöz

Typos included to enhance the readers attention!

[Jeremy Skinner]

Looks good - the only issue I can see is that there's no DisposeInstance method, which could lead to memory leaks with Windsor (see this post for background information). 

I added a DisposeImplementation method (which is called by the IoCControllerFactory) to our current DependencyResolver to work around this problem, so if we go with the CommonServiceLocator we'd have to find a different solution. 

[Simone Busoli]

Do you know how other containers deal with IDisposable components?

[Jeremy Skinner]

I know that Autofac can be configured to scope its components to an HttpRequest automatically, so it will automatically call Dispose at the end of the request. I'm not sure about the other containers.    

[Simone Busoli]

The IoCControllerFactory explicitly disposes controllers, so do we still need to call Release on the container?

[Jeremy Skinner]

With Windsor, yes.

[Simone Busoli]

I looked at how other containers do this. It looks like disposing of components is not handled automatically unless you configure your container in a specific way. For example, with autofac you need to use nested containers as far as I understand, or they won't be released, just as happens with Windsor. http://code.google.com/p/autofac/wiki/DeterministicDisposal

So maybe it shouldn't be responsibility of mvccontrib to dispose controllers. Any thoughts?

[Will Shaver]

It needs to work directly out-of-box. Ideally users of the Windsor and
other container Controller Builders should not have to do anything
extra for this. If we can't accomplish this, at least change the
samples (MvcContrib.Samples.WindsorControllerFactory etc) to show the
proper way to do this and alert users that it needs to be done.

[Jeremy Skinner]

The responsibility for disposing controllers lies with the IControllerFactory's DisposeController method, so our implementations of IControllerFactory need to make sure everything is disposed of and released properly. 

If we abstract the IoC containers behind the CSL, then we lose the ability to do this.

[Simone Busoli]

I looked into this a bit more, and you were right. Windsor is the only one keeping references to components implementing IDisposable, so unless you release them explicitly they will never go out of scope. As I said before, other containers actually need to be configured in a specific way for deterministic disposition, but they don't keep any references to the components, so as soon as they go out of scope they are collected by the GC, although non deterministically.

In the end, we cannot switch to CSL.

[Eric Hexter]

It seems like Windsor is the only container that we have implemented special disposal logic for the container.  That being said.  It seems that we need two controller factories.  IoCControllerFactory and the WindsorControllerFactory. 

Why should we limit the contrib project because one Container is not like the others? If windsor is a special case than it should be treated as a special case.  

I do not think the intention of the IoCControllerFactory is to make it easy for an application to change its Container.  It purpose is to allow the contrib project to maintain less code while providing options. To me supporting the CSL means that we can actually remove code from our project and let the containers which support CSL provide that behavior as part of their implementation.  That seems like a win - win. 

I was chatting with the author of Ninject and he said that our implementation was out of date. That means we as a community supporting the mvc framework have more to maintain than we can actually support.  I see CSL as a way for us to get out of the code that provides little value and move on to supporting higher level features like ajax support , validation, and other features like that.

Am I way off base?  I would love to have some dialog around this type of vision for the contrib project.

[Simone Busoli]

I admit that I find your vision more positive than mine, so I must agree that having an IoCControllerFactory and a WindsorControllerFactory is probably a better way to go compared to leaving CSL in the corner.

I share your vision on the purpose of the IoCControllerFactory, which is to avoid maintaining code that should better maintain the developers of the single IoC containers. 

Of course having two controller factories because one container needs features that others don't is something I would like to avoid, so I hope CSL will soon provide a call to release resources deterministically, since other containers might take advantage of it as well instead of relying on the GC to cleanup objects.

[Jeremy Skinner]

I did a bit more research into the Windsor/IDisposable issue this morning, and the default behaviour can be changed by providing the Microkernel with a custom IReleasePolicy. Something like this should do the trick:

public class ControllerReleasePolicy : Castle.MicroKernel.Releasers.LifecycledComponentsReleasePolicy {

   public override void Track(object instance, IHandler handler) {

     if(! (instance is Controller)) {

         base.Track(instance, handler);

      }

    }

}

Then it can be registered with the container:

var container = new WindsorContainer();

container.Kernel.ReleasePolicy = new ControllerReleasePolicy();

...and now Windsor won't hold a reference to objects that inherit from Controller.

I think if we include a custom ReleasePolicy in mvccontrib, then we can safely use the CSL with Windsor so long as we include a warning in the documentation/samples that the container should be configured to use the custom ReleasePolicy. 

[Simone Busoli]

Actually, you don't even need a custom release policy, there's the NoTrackingReleasePolicy: http://www.castleproject.org/container/documentation/trunk/advanced/releasepolicy.html

[Jeremy Skinner]

I did notice that, but I wasn't sure whether we want to force people to disable tracking on all transient IDisposable objects. The custom releasepolicy will only disable it for controllers. 

[Simone Busoli]

Yes, that's probably the way to go with a custom release policy. So if mvccontrib switched to CSL what would you all prefer?

• IoCControllerFactory + WindsorControllerFactory
• IoCControllerFactory + the advice to use the mvccontrib release policy on Windsor?

[Jeremy Skinner]

Personally I'd prefer the latter. 

[Eric Hexter]

Does any one else have a opinion on a preference?  I do not use windsor so I cannot say what is the best option,

[Simone Busoli]

Well, maybe it's better to wait until more containers provide support for CSL and eventually the IServiceLocator interface gets a method to release components.

In the meanwhile, if I had to choose I'd go for #2 too.

[Will Shaver]

As a MvcContrib and Windsor user, #2 is fine. Just put it in the sample.

 

 -Will

[Simone Busoli]

So far there are implementations for all containers mvccontrib contains implementations for except for ObjectBuilder (does it exist anymore?) and Ninject. Once Ninject is in the switch should be pretty painless.