Is the Repository Pattern the same as the Asp.net Provider Model?

Question

Since Asp.net 2.0, there is the Provider Model. On the implementation detail, a provider is class derived from ProviderBase which is an abstract class rather than an interface, but anyway the Provider Model is there so that we can have different implementation to swap in the out by just editing the web.config. For example if you create a blog app, you may have a BlogProvider : ProviderBase, then you can have implementations of BlogProvider like: SqlBlogProvider, OracleBlogProvider and even MockBlogProvider for testing.

Now, Repository Pattern is getting popular, and I feel it is to satisfy the same need, though in the implementation detail, you normally use interfaces, so IBlogProvider, and you'd inject different implementations through constructors rather than properties, but essentially I don't see the difference in what these 2 patterns gave us.

Personally, I feel Provider Model is more natural for me in the implementation. So, is there a difference between them or they are just the same thing with different names given by different communities?

I'd appreciate any comments on this, Thanks, Ray.

Berne

A similar explanation to the accepted answer below forums.asp.net/t/… – Berne

Answer 1

The Repository and Provider patterns overlap, but they don't formally describe the same thing. I would almost say the Repository is a subset of Provider. In practice, I think the Repository pattern was borne out of a specific need - abstracting repositories - and evolved in the community into a more generic abstraction pattern. In that respect, they have come to be different terms that describe the same concept. However, from the original definitions, they are different in scope:

• The purpose of the Repository pattern is to abstract the specifics of a repository of data away from the application.

• The purpose of the Provider model is to abstract the specifics of anything away from the application. This may be a data repository, but it is just as often some kind of logic.

For example, in our application we have a ContextFactoryProvider, which contains different kinds of logic for determining which ContextFactory to use. There is no repository of data in this case; it's purely application logic that needs to change arbitrarily; the Provider model allows us to use the Single Responsibility Principle to isolate each kind of logic into its own class and swap out that logic easily.

Reginiaregiomontanus

It might also be worth mentioning that it is useful to inject repositories into providers. That way you have the flexibility of varying provider strategies with the added benefit of not tying the provider to a particular repository. 9 out of 10 times I end up with both repositories and providers. – Sgraffito

Answer 2

i can't agree with Rex M. The purpose of provider pattern is to provide support for customization via an abstract interface, where as the purpose of repository pattern is to provide a support to abstract the details of undelying database.

Astrogate