Win a copy of Programmer's Guide to Java SE 8 Oracle Certified Associate (OCA) this week in the OCAJP forum!
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

Who should interact with the rest of the system in a MVC design? Model or Controller?

 
Jin Zhang
Greenhorn
Posts: 28
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi ranchers,

Just read this topic
ubb=get_topic&f=25&t=007536MVC and my design
posted in July 2004 and got confused about who should interact with the rest of the system in a MVC design, Model or Controller?

In Andrew's point of view, its the Model's job:
When the client books a record, the controller will forward the request to the model, and the model send it over RMI to the database. The database-result will go back to the model, and the model updates the Swing-GUI (and maybe later the JSP-view).


But in Mihai's and probably Habibi's as well, point of view, its the Controller's job.
I think you just give to much responsibility to your model.In my opinion the model is a data conatiner, it holds some data and if there are chenges in its state may be it notifies its observer.The controller is responsible to interact whit the rest of the system.


So, who is correct? Or both? BTW, I used the second approach, because I bought Habibi's book

Thanks & Regards,
Zhang Jin
 
Inuka Vincit
Ranch Hand
Posts: 175
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I am assuming the rest of the system means the database. In my case I used the model as well. The way I understood it was the the controller that handled all the events related to the GUI, and the view was the GUI itself. Since the model handles all the data that is viewed by the GUI to me it was the natural choice. I used the MVC pattern more as a guideline, my VC are in one class.

The ultimate decision is upto you realy. In software design there is no right or wrong answer as long as you break the functionality cleanly your fine. Although you will find architechts who aruge for long hours insisting they have the right answer, and a manger will ultimately step in and make the choice for them . But you dont have a manager .

I thought Andrews threads provided me with a far far better refrance than Max's book(I eventually never reffered to it). Not saying who is more right, but just saying the guy knows his stuff damn well.
[ November 20, 2004: Message edited by: Inuka Vincit ]
 
Jin Zhang
Greenhorn
Posts: 28
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi Inuka,

Thanks for your explaination.

My code of the View is something like (for search):

JButton searchButton = new JButton("Search");
searchButton.addActionListener(new SearchRecord());

And the inner class SearchRecord is my Controller:
private class SearchRecord implements ActionListener {
public void actionPerformed(ActionEvent ae) {
...
tableModel = controller.findRecord(criteria);
mainTable.setModel(tableModel);
}
}

The controller.findRecord() method talks to the DB and creates the Model, which implements the AbstractTableModel interface. Then the JTable's table model will be updated by the setModel() method and the view will be changed.

So, in this design it is the controller who talks with the DB. Do you think this design is OK? I feel it is quite "nature"

Can kindly share your code with me for how to use the model to do the job?

Thanks.

Cheers,
Zhang Jin
 
peter wooster
Ranch Hand
Posts: 1033
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by Jin Zhang:
Hi Inuka,

Thanks for your explaination.

My code of the View is something like (for search):

JButton searchButton = new JButton("Search");
searchButton.addActionListener(new SearchRecord());

And the inner class SearchRecord is my Controller:
private class SearchRecord implements ActionListener {
public void actionPerformed(ActionEvent ae) {
...
tableModel = controller.findRecord(criteria);
mainTable.setModel(tableModel);
}
}

The controller.findRecord() method talks to the DB and creates the Model, which implements the AbstractTableModel interface. Then the JTable's table model will be updated by the setModel() method and the view will be changed.

So, in this design it is the controller who talks with the DB. Do you think this design is OK? I feel it is quite "nature"

Can kindly share your code with me for how to use the model to do the job?

Thanks.

Cheers,
Zhang Jin


You shouldn't confuse the TableModel with the Model in the MVC pattern. The database server (or some facade on it) is the Model in MVC. If you substituted a Tree view, which didn't have a TableModel, the database server would still be your model. The TableModel is part of the Table View.
 
Jin Zhang
Greenhorn
Posts: 28
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi Peter,

I think I am more confused... , especially after reading more MVC threads in this forum. It seems that some people's idea is same as mine, the TableModel is the Model in the MVC. It is abservable by the view, which is implemented by Swing internally. But if we are correct, I cannot see the benifit of the MVC at all. Because as you said, if the JTable is to be changed to a JTree, all the M, V, and C need to be changed. So, it seems we are not correct...

Also, is my design using MVC after all? If yes, can help to point out which class is the M, which is V and which is C?

Really appreciate your help.


Zhang Jin
 
Jin Zhang
Greenhorn
Posts: 28
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi all,

After hours of struggle, I think I got a solution of my MVC design in the project.

I will rename my current controller class to DBClientFacade and make it as my Model of the MVC. It will be changed a little bit to return a more generate type, such as ArrayList for the search method, instead of the TableModel instance. So it can be reused. Also, the current Controller in the MVC, which is the inner action listener class, will be responsible to convert the ArrayList to TableModel and fires the change to the View.

I am quite satisfied with this modified design . Any comments?

Again, thanks all for your kindly help.

Cheers,
Zhang Jin
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic