Can someone please explain which part of the provider model best represents the business layer?
Where should the business rules and business logic live?
Can someone please explain which part of the provider model best represents the business layer?
Where should the business rules and business logic live?
If you mean something like the Membership Provider in .net, I would say the Business Layer uses the providers as a service (like John states). Though the line is a little gray if you are implementing providers yourself (like is a user a business object? if so what about the rules in the provider logic?).
Typically providers are developed separately from business applications because they are more infrastructure type code.
However, if you are just interested in the provider portion then, you typically have the following parts in a provider: 1. infrastructure stuff (config reading/database communication/etc) 2. provider interface (provides the service to consuming code) 3. 'business' objects and rules
I guess the business layer would be the implementation of the specific provider (there is usually a base class that implements the infrastructure stuff). For instance the membership provider deals with user and membership objects and has a few rules on how to do what it does as a provider.
Unless you're talking about a different "provider model" than I am, there is no relationship to a business layer.
A provider model is simply an architecture where one or more components provides a set of services. For instance, in LINQ, a LINQ Provider provides the mapping to a data store or other source of data, while the .NET Framework classes provide the rest.