Provider Pattern (Overview)

Provider Pattern

A provider is simply a contract between an API and the Business Logic/Data Abstraction Layer. A provider implementation must derive from an abstract base class, which is used to define a contract for a particular feature

Common Behaviors/Characteristics:
Below is a listing of characteristics common to providers.

1. Base class
A base class should have as few methods and properties as possible. This is desirable to encourage developers to write providers.

2. Threading
Providers should be free-threaded/thread safe, with one instance per application domain. Any provider-specific objects created more frequently (for example, one per request) should be created through provider APIs.

3. Factory methods
The abstract base class should support factory methods to create new objects wherever appropriate.

If a feature allows a provider to create a framework object, but does not allow the provider to extend the object, the framework class should be sealed.

Complex objects created by a provider may keep track of the provider that created it, and expose it as a Provider property. This allows users of the feature to determine the provider that owns the data for the object. For example, when a new user is created with the Membership API, it may be useful for the developer to be aware of the provider that data for the object is stored in.

4. Class naming and namespaces
The specific provider base classes should be named [Feature]ProviderBase.

5. Common naming patterns for provider classes
Figure 5 below calls out some of the common names and casing that should be used for various data stores (where name is [Name][Feature]Provider).




Refrence: Provider Model Design Pattern and Specification, Part 1

Sample Code HERE

Good Luck & happy programming.