Hi there.
Ive just been reading about the Whidbey Provider Pattern on MSDN,
http://msdn.microsoft.com/library/de...sp02182004.asp
and i wanted to clarify my understanding of it and get some
implementation feedback. Im a bit unsure so please correct me.
What Im Doing
Ive a classic 2/3 tier app that i'M partioning,
UI(webforms/winforms+functi onal restrictions), common business logic
layer and then a DAL, i want to offer on both Access2000 and SQL
Server. I figure this Whidbey Provider pattern is where its at for
swapping my DAL in and out thru app.config.
I basically want to know how others have done it. This what i did but
im wondering if i've done everything i need to and/or have i have used
the framework to its full potential.
How I Did It / My Understanding
I'll use points to save on the typing. They represent my current
understanding and may seem like statements but their kinda questions
as well, please yes/no me if you have the time.
1. This pattern is going to be used extensively in the Whidbey release
of the framework.. Microsoft recommends getting into it now but if you
do you'll have build your own provider base etc.
2. First up i partioned my app into 3 standard tier and put a shared
(static) field into each of the classes in the BL that needed data.
This was to a fairly generic class, say CustomerProvide rBase for the
Customer class. CustomerProvide rBase had subclassed ProviderBase.
3. Then i created separate assemblies which subclassed the provider
base classes in my BL (engine) assembly so for instance in an assembly
MyApplication.P rovider.Access, i had subclassed the
CustomerProvide rBase from the MyApplication.E ngine assembly to create
an AccessCustomerP rovider class.
I did this for all Provider classes in the MyApplication.P rovider
namespace of the engine
assembly so that i now had AccessProviders for everything in that
namespace.
4. Then in the app.config I created an application section group and
sections for all of my "features". I understand this "features" term
used in the aforementioned Url to mean providers.
This meant i had a section for each provider class in my engine/BL.
Each of these referenced a CustomSectionHa ndler i had to create to
read in the section XML for each of the "features" so it would return
a ProviderBase object from
ConfigurationSe ttings.GetConfi g("mysectiong rp/sectionname") as Object
5. Then i went thru and entered all the section settings into the
app.config for the intended DAL.
6. This means in my app.config i have configSection declarations for
each of the provider classes declared as shared fields in each of
engine/BL classes. Plus then settings for each each of the sections.
Is this right?
This means i dont swap the whole DAL from Access to SQLServer with a
single entry in the app.config but rather make a setting change for
each provider class referenced by a feature?
So if i have 10 business classes all requiring data, they would have
10 shared fields each pointing to their respective ProviderClasses ,
and 10 section declarations in configSections and 10 section settings
in the app.config and when i wanted to swapp from A2K to SQL i make 10
section setting changes (1 for each of the Providers) in the
app.config.?
Is this how you guys/girls are doing it?
Its really flexible, I can see that... It completely abstracts away
the DAL from the BL by putting a Provider layer/interface between the
BL and the DAL. Data could be coming from pretty much anywhere and the
app wont care....
It works great but i am i doing it right? It feels like im long
handing something thats supposed to be shorthand.
Thanks for any thoughts.
Richard.
