Hi all,

On page 223 we have this property below, this property is part of the ArticlesProvider class.

static public ArticlesProvider Instance
{
     get
     {
     if (_instance == null)
         instance = (ArticlesProvider)Activator.CreateInstance(Type.Ge tType(Globals.Settings.Articles.ProviderType));
            return _instance;
     }
}

Now I know this returns an instance of our provider type, which is the SqlArticlesProvider class, but a cast is done here converting it into its parent class; the ArticlesProvider class. Ok, all good so far. Now on page 228 we have a property within the SiteProvider class that simply uses the property above to return an ArticlesProvider instance, like so:

public static ArticlesProvider Articles
{
    get { return ArticlesProvider.Instance; }
}

All good so far. Now on page 231 we have the body property like so:

get
{
    if (_body == null)
        _body = SiteProvider.Articles.GetArticleBody(this.ID);
        return _body;
}

Now I can see that this uses the Articles property previously created in order to get an instance of the ArticlesProvider class, but appended to this is the GetArticleBody() method, and this is where I get confused. The ArticlesProvider class defines this method as an abstract method, the SqlArticlesProvider class provides the concrete implementation of this method BUT how is it possible to access this implemetation from the ArticlesProvider class? Remember that when we got the provider type we cast it into its parent ArticlesProvider class (as shown in the first property above) so it is no longer a SqlArticlesProvider instance, so how can we access the SqlArticlesProvider methods like this?

Hope someone can help.

Thanks

crazy - you delve too deeply :)

i'll take a look and 'hopefully' come up with something short of bullsh$t in the coming days!! i have to admit, i've naively accepted the casting and delegation and followed the factory pattern methodology, without too much question (in fact, i've been using the devilish tool from http://www.flixon.com which is coming in to it's own now. this tool takes a table def and creates the full dal and bll code as per the beerhouse standards - it's excellent. i'm just ironing out a few wrinkles with the author as we speak and hopefully a v1 is imminent)

as i said - i'll take a look and might even engage the old brain irrespective

jimi

http://www.jamestollan.com

crazy - you delve too deeply :)

This is probably why I'm crazy!!!

Thanks jimi, I would appreciate any help, I don't like getting stumped like this!!!

Thanks

Hey crazy,

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:

http://aspnet.4guysfromrolla.com/dem.../101905-1.aspx

Hope that helps,

C.

Hi Chris,

Thanks for your response. I'm still a little confused though. I fully appreciate the reason for placing the provider type in the web.config file, but it's still that cast that throws me.

If the ArticleProvider class wasn't declared as abstract would the cast produce an ArticleProvider instance instead? I suppose I'm asking if a cast acts differently depending on if the parent class is abstract or not? If it isn't an abstract class then the cast would return an instance of ArticleProvider but when it is an abstract class a cast simply indicates that the type inherits from the type specified in the cast, in this case ArticleProvider. Is that correct?

Thanks for your help.

Hi crazy,

You can't ever create an instance of ArticlesProvider - it's an abstract class. It's purpose is to ensure that all types that inherit from it implement certain properties and methods.

As for the cast, I'll refer to MSDN documentation for Activator.CreateInstance():

public static Object CreateInstance (Type type)

Note the return type - Object! We actually need our provider to be of a type that inherits from ArticlesProvider (that way we can access the inherited methods). Since CreateInstance returns Object, we need to cast it to a type that inherits from ArticlesProvider (In TBH, that's the SqlArticlesProvider in web.config, but could be any provider for which you want to support).

This can be confusing at first, and I hope I haven't muddied the waters even further. It's an exceptionally powerful paradigm, and if you haven't read the article I sent you, I'd suggest having a read of it. This stuff will make more sense.

Chris

Hi Chris,

Thanks again for your response but I'm afraid I'm still not quite there yet. I fully appreciate and understand that you can't create an instance of the ArticlesProvider class. I now understand that the CreateInstance() method returns an object object rather than an SqlArticleProvider object which is why we'd need to do a cast (I should have checked this, silly me) but that cast is still an ArticlesProvider, the Instance property even returns an ArticlesProvider but as you say you can't do this as you can't create an instance of ArticlesProvider. So how does this cast translate as an SqlArticlesProvider instance when the cast is clearly to the base class ArticlesProvider? I know we wouldn't want to cast to a SqlArticlesProvider as that would be of no use if someone used a different backend, but somewhere this Instance property must be returning an SqlArticlesProvider instance or we wouldn't be able to access its members. Where is this happening and how?

I read the article but it didn't explain anything about this type of cast.

Thanks for all your help so far, I'll understand if you've lost patience with me.

Crazy

Hi Chris

Not to worry now I've worked it out. I had to go back to basics and do some inheritance testing before I got it. Thanks for all your help, you definitely got me thinking and on the right path.

Cheers
Crazy

Hi Crazy,

It doesn't matter if the object instance is cast as an ArticlesProvider. The instance is still a SqlArticlesProvider instance.

I have recently been introduced to Spring and Spring.NET, and so I now referred back to TBH's factory implementation with Site Providers. It got me thinking - how does Microsoft's provider model fit with Spring? How easy or difficult would it be to combine TBH with Spring, and would it make sense to do this? Could someone familiar with Spring please comment on this?

Alex

Alex

- TheBeerHouse Mods Repository
http://www.sashka.com/TheBeerHouse/thebeerhouse.html