CODEWITHSUNDEEP
inversion-of-controldesign-patterns
blahblah
blahblah

Reputation:

Is the provider pattern an implementation of IOC?

Is the provider pattern an implementation of IOC? If not, why not?

(reading through martin fowlers article on ioc)

Upvotes: 3

Views: 1371

Answers (3)

nootn
nootn

Reputation: 861

I think even if it is, you shouldn't necessarily use it "instead of" IOC or you will be missing out and have a messy code base. IOC containers can generally be configured in code which can be more powerful and far easier to maintain, whereas the Provider Model must be configured in the Web.Config.

I am actually considering moving away from the Provider Model now that I am using an IOC container because it seems like overkill.

Read more on my blog post - hopefully the blog will get some good comments about it too: http://healthedev.blogspot.com/2011/12/making-custom-built-applications.html

Upvotes: 0

Jack Ukleja
Jack Ukleja

Reputation: 13511

In my opinion, yes the Provider pattern is a form of Inversion of Control.

What's my reasoning?

At it's core IoC is a very generic concept, so much so that Martin Fowler talks about reading user input from the command line as being a form of IoC.

With the Provider model the inversion happens when the provider framework decides which provider will be used when a given method is called. For example when you invoke Membership.GetUser your code is delegating control of which Membership provider to use, to the provider framework.

As Fowler says "Inversion of Control is a common characteristic of frameworks" and if you think about it many patterns are concerned with IoC (e.g Strategy pattern). I would go as far as to say that even polymophism is a form of IoC (a point I would happily like to hear a counter argument to).

Upvotes: 7

duffymo
duffymo

Reputation: 308763

Spring uses BeanFactory and its concrete implementations, most important of which is ApplicationContext. Don't know what Guice does.

Upvotes: 0

Related Questions