Should controller lifestyle always be transient in Windsor configuration for ASP.NET MVC?

I ran into a problem where I had an Html.DropDownList in my view 开发者_如何转开发that would postback the selected value the first time I submitted the form, but each subsequent postback would only post data from the initial postback. So I added lifestyle="transient" to the component element where I had configured my controller for castle windsor, which fixed the problem, but of course made postbacks take longer since a new controller was being instantiated per request. Given the information above, what insight, suggestions, or solutions might help determine my original question about the controller lifestyle? Thanks for all the help and support!

MVC controllers are transient. Thinking about it, this makes sense for a few reasons. First, if a single instance is used to service multiple requests and if multiple requests happen to hit the same controller at the same time, you're going to experience some fairly bizarre race conditions. Second, HTTP is by its very nature stateless, and requests exist independently of one another. This is reflected in the transient lifestyle of controllers.

Transient, yes, but for interest sake, why not PerWebRequest instead of Transient? I've seen a couple of blogs that use PerWebRequest lifestyle and I can't think of a reason why not. Any answers?

I agree with Dion. Landed here looking for solution to this same question. It seems like PerWebRequest is more appropriate.

Depending on how you integrate your container into MVC and WebApi, you might not be instructing Windsor to release dependencies when your controller isn't being used anymore.

If you set it to PerWebRequest, it will automatically release your controller, and all its dependencies when the request ends

The use of Html.Action in Views leads potentially to more than one request per Controller, originating the error «A single instance of controller XPTO cannot be used to handle multiple request», if the Controller lifecycle was PerWebRequest.

Check Robert Muehsig (https://blog.codeinside.eu/2011/01/18/fix-a-single-instance-of-controller-foocontroller-cannot-be-used-to-handle-multiple-requests-mvc3/), here translated from German: «The problem occurs when you enter, for example, LifestyleType.WebRequest and call a controller several times via RenderAction - the framework doesn't like that and the fancy error message appears. The reason is simple: an HttpRequest arrives, so exactly one instance of the controller is created. He then wants to access this instance several times via RenderAction, which is probably not possible»»