CODEWITHSUNDEEP
.netasp.net-mvcasp.net-mvc-3dependency-injectioninversion-of-control
AnyOne
AnyOne

Reputation: 931

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 in Global.asax and always access my container via a static class?

Upvotes: 3

Views: 1747

Answers (3)

Mark Seemann
Mark Seemann

Reputation: 233150

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).

Upvotes: 8

brodie
brodie

Reputation: 5434

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.

Upvotes: 6

Otávio Décio
Otávio Décio

Reputation: 74260

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.

Upvotes: 4

Related Questions