Can Can Castle Windsor be used to implement IDependencyResolver in ASP.NET MVC 4?

Question

I read this article and saw that many people have commented that they are not using Castle Windsor to implement IDependencyResolver in ASP.NET MVC3 and adhere to custom IControllerFactory. Mostly my questions now:

• Do not use Castle Windsor to implement IDependencyResolver. Is this still true in ASP.NET MVC 4 ?

• If so. Can any other DI container (Unity, StructureMap) have the same problem as Castle Windsor? Can I use any alternative?

thanks a lot

EDIT

It seems to me that Castle Windsor should NOT be used to implement IDependencyResolver . I decided to use another DI container like StructureMap

Answer 1

There is no difference between MVC3 and MVC4 with respect to IDependencyResolver, except for the fact that there is a separate resolver for the WebAPI.

In my opinion, Mike Hadlow is too elegant about this subject, and many other people jumped on the bandwagon without thinking about why.

Yes, it’s true that Castle Windsor has a specific object style (such as a lifecycle management object) called Pooled, which often requires you to call Release on it. And when using this lifestyle, you probably shouldn't use IDependencyResolver because it does not provide access to this Release method (although there are ways around this too).

However, I find that using this lifestyle in a web application is usually bad, and instead you should use the PerWebRequest style, which automatically frees objects at the end of the web request. If this is what you are using, then there is no problem using IDependencyResolver with Castle Windsor.

Why do I think Hadlow is too caustic? Well, because he bases his entire argument on this:

"That's right, no." Release method. You can provide the service from your IoC container, but this is not a way to clear. If I were going to use it at the Suteki Shop, I would have a memory leak from an epic proportion. "

He then continues to refer to Krzysztof Koimik's article on lifestyle management, but neglects the link to his next article, which I will do here:

http://kozmic.net/2010/08/27/must-i-release-everything-when-using-windsor/

Pay attention to what he says here:

"Since, as I mentioned in my previous post, Windsor will keep track of your component, it's a common misconception that belongs to users , so that they must call the Release method in the container to properly release all components."

He discusses other aspects further, but overall I don’t think that most people will use Pooled or Transient objects that require removal in a web application. And if you do, then you should not use IDependencyResolver. Otherwise, you should not have a problem.

I know that I will probably get a lot of grief from people who argue differently, but I just don’t see the end of the world question in this, which seems to be what Hadlow seems to think, because there are so many alternatives, and workarounds, even if you need to call Release.

On top of all this, using a lifestyle that requires a Release call means extra work for you, the developer. Now you need to control the lifetime of the object and remember to delete the objects, and this does not create a memory leak. This essentially nullifies the benefits of garbage collection, in my opinion. I use only temporary objects with things that do not need to be disposed of, and I never use combined objects.

By the way, I can be wrong, but I do not think that any other capacity has this problem. This leads me to conclude that it is a Windsor that is broken, not MVC, when every other container there seems to have no problem with this. Windsor loves to stubbornly hold on to his version of reality, though, which is why YMMV.

Answer 2

The advice not to use IDependencyResolver stupid because it can be used with Castle Windsor, although the interface does not have a release method. The solution is to allow the IDependencyResolver implementation IDependencyResolver each requested instance (in a cache limited by a web request, for example using HttpContext.Items ). At the end of the web request, all cached instances (usually several) can be freed.

To be able to release all instances at the end of the web request, you must either register the Request_Ends event in global.asax or register an HttpModule that will do this.

You can call it a workaround, but not using IDependencyResolver is actually not an option, as it is too deeply integrated with MVC. In addition, other containers (such as Ninject and Simple Injector) use the same approach (using the HttpModule) to "release" instances.

It’s unfortunate, however, that there are no official NuGet packages for omtegrating Windsor with MVC, since now you have to implement this yourself. All other frameworks have such a package. But then again, it is not so difficult to implement it on your own.

Other IoC containers already show that you can implement release as an implementation detail, and you do not need Release as part of the IDependencyResolver contract. MVC designers did the right thing by removing this method from the API.

Answer 3

While I agree with the implementation of IDependencyResolver, it may not be very difficult .. and yes, depending on the lifestyle in the game, obviously Release () may not matter ... and yes, there are ways to force Release () to cache the instance somewhere , as well as other subtle tricks - I think it is a lot to go into interpretation and can be problematic and hard to track. Understanding when Windsor is about to track an instance does not always immediately become apparent (i.e. if the component has problems with disabling, rather than lifestyle, etc.). One of the main added values ​​of IoC is the centralization of responsibility for creating objects and managing instances. To do this correctly and have a separation of problems - you need to have an architecture that you can trust that will serve you well in call scripts, and that IMO means having iron-clad answers for the Release () instance for all tastes. My advice is to always implement a project that will allow you to call Release - especially at the root (for example, the controller).

The final argument against IDependencyResolver is that you need to register several components of the MVC system if you integrate at this level. This is too intimate a dance between my application and the frame under it for my taste. IControllerFactory provides a much more targeted integration point, you do not need to register the components of the MVC system, and you get hook Release (). Therefore, if you do not want to redefine the components of the MVC system, I see very little reason to implement IDepedencyResolver over IControllerFactory. In fact, I see the opposite argument. I personally guessed about this in this thread here , which shows both approaches.

Hope this helps