Win a copy of Re-engineering Legacy Software this week in the Refactoring forum
or Docker in Action in the Cloud/Virtualization forum!
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

MVC

 
Herbert Sch
Greenhorn
Posts: 1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Sheriff
Posts: 48445
56
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
"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
Ranch Hand
Posts: 2187
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Author and ninkuma
Marshal
Pie
Posts: 64632
86
IntelliJ IDE Java jQuery Mac Mac OS X
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Perhaps this article will be helpful.
 
Ilja Preuss
author
Sheriff
Posts: 14112
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Ranch Hand
Posts: 51
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
author
Sheriff
Posts: 14112
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I mostly use variants of Model View Presenter.
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic