You may have noticed that ArticlesProvider is an ABSTRACT
class. That means that you can't actually create an instance of it.
Take this syntax:
ArticlesProvider ap = FactoryObj.CreateSqlArticlesProvider()
ap is NOT of type ArticlesProvider, the declaration ensures only that ap is of a type that INHERITS
from ArticlesProvider, in this case SqlArticlesProvider.
So, what's the big deal? Let's re-visit that line in the Instance property:
instance = (ArticlesProvider)Activator.CreateInstance(Type.Ge tType(Globals.Settings.Articles.ProviderType));
This cast ensures that the Activator creates an object that inherits from ArticlesProvider. The ProviderType is declared in our web.config, but what if we didn't want to use Sql Server anymore, and we needed to migrate to MySQL?
After creating a section in the DAL whose only purpose is to shuttle data back and forth between MySQL (the MySQL Client, if you will), we could begin referencing our new MySQL database simply by changing the ProviderType in the web.config!
If the data access code wasn't written this way, we would have polluted our entire DAL with SQL Server specific code. To migrate, you would have needed to go through all your code looking for SQL Server connections, commands, parameters, etc... and change them over to MySQL objects. I've been there before, it's not fun.
This way, we create a specific client for each data provider we want to support in the DAL, update the web.config and we're done.
There's a better explanation of the Provider Model here:
Hope that helps,