I would like to have a clarification in MVC Architecture . While going through some of the documents, I could see that the following relationships are established between Model-View and Controller. Please help me in understanding how this is possible.
Generally speaking, what you describe would be done by the controller. The controller would query the model, interpret the data, and send it to the view for display in the form the view understands.
However, MVC isn't a hard rule. There are many interpretations, and when doing it "correctly" would be uglier than bending the rules a little, the latter is usually preferable.
MVC Follows some simple rules.
Your model will generally map to a database table. For example if you have a "blogposts" table that has two columns, "title" and "body", you could do:
Blogpost.create(:title => "Hello", :body => "World")
You just created a blog post! Now, in your controller you will do something such as:
blogs = Blogpost.find(:all)
You may now pass the 'blogs' variable into your view, and it can decide how to display that data to the user. Sorry if my example code wasn't pefectly clear, it is written in Ruby (on Rails), which is my current MVC language of choice.
Let's say you have an object called View and an object called Model. Each object holds a reference to the other. The way you described would work is that View would call a function in Model asking for the status of Model and Model would return the information it wants. A more efficient way of implementing it is that the Model will tell the State when something has changed and View will then ask for the information it wants. I don't have a code example on me, but you might want to look into using the Observer design pattern for this.
I've seen a document describing the "triangular" form of MVC before, and I suppose someone at some point got it to work (either that, or documents about it are just talking about vaporware). However, I haven't found much practical use in it, as it leads to a serious software "engineering" problem: Circular dependency. If your view depends on the exact shape of the model for it to do some querying, and the model depends on the exact shape of the controller, and the controller depends on the exact shape of the view, then it becomes rather impossible to actually swap out any of those elements.
I've found it much useful to have a model that doesn't depend on anything more than a simple command line program would depend on. A view that doesn't depend on anything aside from whatever gui toolkit, or graphics drawing api you're using, and a controller that acts as a broker between the two, enabling this decoupling. This is a strategy that lets you create models and views that are modular and interchangable, leaving just a single component: the controller, with all those nasty dependencies.
Of course, there might be some kind of "Official" version of the MVC pattern, but I haven't been able to make my way through any document purporting to describe such a thing in tact, with any great sense that it really applied to real world systems. But maybe I'm just kinda dumb that way.