When should I use a static IoC container?

Some programmers access their IoC containers with static class methods. Is it just a preference, or is it a requirement?

If my custom membership provider needs DataContext, how can I inject my DataContext into it without a static class?

My approach is to access my container via a static class inside of custom membership provider. Is it right solution?

If the static way is preferred, do I have to keep my base container in singleton scope and initialize it i开发者_C百科n Global.asax and always access my container via a static class?

A static Service Locator is just never a good idea. The ASP.NET Provider model suffers from the Constrained Construction anti-pattern, as well as a host of other issues. It's better to avoid if at all possible (it usually is).

The most common reason for avoiding static IoC access or Service Locator pattern is that it adds an additional dependency which complicates unit testing.

You should prefer to use constructor injection where possible.

Also here is a potential solution for you where someone is using custom membership provider and dependency injection.

See this other question for a good discussion and you can also read up on some best practices on the autofac site.

There is no requirement that IoC containers have to be static, in fact you can create as many as you wish - it all depends on what you need. As you probably found out, there are cases where you need a static container.