hi,
Could anybody please explain the following scenarios? I am confused what is going on in these classes.

1)Why do we need to create an Instance of "ArticlesProvider" type in ArticlesProvider.cs ?

2)In SqlArticlesProvider.cs, it is creating a connection as follows.
using (SqlConnection cn = newSqlConnection(this.ConnectionString)

I dont understand where it is getting the ConnectionString from? because we dont have any connectionstring object associated with this class. what is it taking when it uses "this.ConnectionString" ?

3) If I dont want to use this provider pattern then do I also need to remove ArticlesProvider.cs and directly inherit DataAccess.cs from SqlArticlesProvider.cs ?

Thank you very much for any clarifications or suggestions!

Jyothi_23,

One of the keys to Object Oriented Design and Programming is abstraction. From your questions I think this is what is confusing you. Abstraction is removing all the details and reducing something to it's essence.

The ArticlesProvider.cs is an abstract class (means it can't be instantiated/created, but must be implemented by another class. The SQLArticlesProvider implements the ArticlesProvider
Much of the code, but not all, in the AriclesProvider are declarations of methods that the class that implements it (SqlArticlesProvider) must also implement the methods (actually provide the code to make them do something).

Now to your first question. In C#, unlike in VB, the constructor for a class has the same name as the class itself, so you see a class & file named ArticlesProvider and a constructor method also named ArticlesProvider. but I just stated an abstract class can't be instantiated, so why does it have a constructor? I'm not going to provide a full answer because it makes me feel like I have bees in my head to think about it, let alone try and explain it. What I will say is the constructor is static, meaning it can be called on the class itself not from an object created by the class; and it implements the singleton pattern. The singleton returns and instance of an object if it exists, or creates one if it doesn't; there can only be one of them, hence the name, singleton. This is actully called from the DAL/SiteProvider.cs, which in turn is called from the Article Object. It's convoluted and elegant at the same time; and difficult to wrap your head around. The bottom line is when you want an Article provider you get a SqlArticleProvider object that implements an ArticleProvider and there is only one of them for the entire application.

Moving on to #2, which is much easier. The this.connectionString in the SqlArticleProvider refers to this.connectionstring in the Abstract class ArticleProvider's constructor, where it is loaded with the Globals.Settings.Articles.ConnectionString; which will take you to the ConfigSection.cs file, which will lead you to the connectionstring enty in the web.config file. Also convulted but not nearily as much so as the previous question. One of the ways I use to figure out how things work in TBH is to put my cursor on something, right click and then select Go to Definition. I find this really helps trace though the logic.

Number 3 You could just use a datasource and connect it to a datagrid and be done, but it wouldn't scale very well or be very flexible. That is the power of n-tier development, it can scale and be flexible. With very little work, once you understand what's going on you can easily create your own modules to do just about anything you can imagine. I've modified the articles module into a resource links module, a job postings module and a meetings module.
The ArticlesProvider module, provides the singleton, which is important as well as all the virtual methods you need; and defines the signature for the methods you will still have to have that do the heavy lifting. Rather than fight it try to understand it. It really is a nice piece of architecture. If I knew enough to build it from scratch it's the way I would build it.

If I made any errors in my explantion, hopefully someone will point them out and correct them.


Steve

Hello Steve,

Thank you very much for the wonderful explanation and appreciate for taking time to give such an elaborated description. The 2nd and 3rd points are pretty clear for me now and I am able to understand what you were saying in the first point. But I do have another question here. Could you please have a look at them when you get a chance?
Thank you for your help!

1) If we want to implement Provider pattern, is it a compulsion to have an abstract class and create the instance of providerType only in that abstract class? Or is there any other place we can place this code so we can completely remove the abstract class? I understand this abstract class is also useful to declare any abstract methods and also provides some functionality.

2) If we want to choose another provider (say Oracle) what all places we need to make changes? I guess we need to make modifications in sqlArticlesProvider to support Oracle commands etc. Please let me know if you have any idea on this.

Thanks!
Jyothi

Jyothi,

You do not have to exactly follow the architecture Marco has provided in his book, but if you deviate from it you need to know what you are doing and why you would want to change it. Think of it as a recipe, you can change this or that in the recipe, but at some point it becomes a new recipe. If you don't know why each ingredient is included, or the amounts being used, you may or may not end up with a meal worth consuming. The functionality outlined in the abstract provider classes is needed, it has to go somewhere, the abstract class is the logical best place for the very reason you ask in your second question.

To switch to Oracle you only need to change the SqlProviders and make them OracleProviders. If you leave the abstract providers as they are you would simply have your OracleProvider implement the abstract providers and move on, job done. If you try to embed the abastract provider into the SQL provider you would then need to make all those same changes into an Oracle provider.

This is covered in pretty thorough detail in Chapter 3 of the book in the section "Designing a Layerd Infrastructure" You might want to read it a few times to really understand the elegance of what Marco has provided us.

Good Luck


Steve

Hi Steve,

Thanks for all the clarifications. I will again go through "Designing a Layerd Infrastructure" as you suggested.

-Jyothi