MVC

[Herbert Sch]

Hi,

Would you please confirm if my following understanding of MVC is correct?

View: Any controls on the UI which just displays the data. e.g. Listview, comboboxes. (As long as they just display the data and they don't intend to modify it in anyway).

Controller: Any controls on the UI which allows user to update/delete the data. e.g. Submit Button

Model: The actual interface to the database. Model is accessed by both the View and the Controller. Controller accesses the model after user clicks on the user control meant for updating the data (e.g. a button). Once the Model is updated it notifies all the listeners (i.e. all the views) of the change. Views then accesses the Model so that the changed Model can be shown on the UI.

Model will typically have Get and Set methods. Am I right in saying that Set methods will be accessed by Controller where as Get methods will be accessed by View?

There can be any number of Views and Controllers depending on the number of user interfaces for a particular application but there will always be only one Model.

Thanks
HS

[Campbell Ritchie]

"Herbert Sch" you have managed to keep us from finding out about your displayed name for 6 months, but if you make a posting, we notice it!

We have a naming policy which requires first name-space-last name, not such an abbreviation. Please go to "my profile" "update profile" to correct your name to comply.

CR

[Jimmy Clark]

Model-View-Controller design pattern separates the different parts of a software application that interacts with a human. The human makes requests and/or sends data for processing. The application receieves requests, does processing and sends responses to human.

The Model component contains the business/domain logic of the business model. This includes application data and possibly a relational database.

The View component contains the presentation code the generates a GUI for the human. The View code and the code of the Model never communicate directly with each other. All communication between the View and the Model are handled by the Controller.

The Controller handles all communication between the View and the Model.

The primary purpose of this pattern is to have loose coupling between the Model and the presentation code. Or, in other words, as you can see, the Model code has no dependencies upon the View code. The Model code only reponses to a Controller. Note, there are no dependencies upon the Controller. A Controller depends upon and is based on the Model API.

[Bear Bibeault]

Perhaps this article will be helpful.

[Ilja Preuss]

Originally posted by James Clark:

The View component contains the presentation code the generates a GUI for the human. The View code and the code of the Model never communicate directly with each other. All communication between the View and the Model are handled by the Controller.

The Controller handles all communication between the View and the Model.

That's actually closer to Model View Presenter, where the View handles both input and output, and the Presenter acts as a Mediator between View and Model.

In the original MVC, the Controller is responsible for handling incoming requests, initiating the appropriate reactions in both Model and possibly the View. The View also reacts directly to changes in the Model, decoupled by the Observer pattern.

The intent of MVC is to not only decouple the domain logic from the input/output logic, but also to decouple the input and output logic from each other, so that they can be exchanged independently. As far as I can tell, it isn't in much use in its pure form these days.

[Gulsum Ramazanoglu]

Ilja said ;

As far as I can tell, it isn't in much use in its pure form these days.

May I ask; what would be a good approach? What kind of an approach I must develop, if it wont be MVC?

[Ilja Preuss]

I mostly use variants of Model View Presenter.