In my package design, i consider Model, View and Controller all as part of the GUI. But the MVC architecture does not specify what kind of View is used (that is in fact one of the advantages of it). So a "graphical user interface (= GUI)" is only one of the possible views which can be plugged in. But also text-based or even sound-based "views" are possible within this architecture !!! That makes me think that the controller and model classes do not belong in a package ~.gui, but rather in a package called ~.client or so. The gui package (maybe better called ~.swingview) would then be a subpackage of the client package. Who wants to shoot at my consideration... ? ;-) GReetz Klaas
[ August 26, 2004: Message edited by: Klaas van Gelder ] [ August 26, 2004: Message edited by: Klaas van Gelder ]
"What you don't know, can't help you"
SCJP (81%), SCWCD (81%), SCJD (354/400), SCBCD (85%)
I think the model is the data base and controller is something that stays in between the model and the view. I think the controller could have methods like delete all data base, even though the model does not have this ability. The gui is something that stays at the top of them and could be in a packet suncertify.gui If we were supposed to make a web-based system, perhaps our "gui" could stay in suncertfy.web (where there would be servelets).
finally, I don't think Model and coltrol should be in the same packet as the view. Was it what you said or am I wrong?
Thanx Itapaje, i think we agree on the point that model and controller are not part of the gui ! I wonder in which package you have placed these classes. The root package suncertify appears too general to me. Grtz Klaas
If you mean Swing model eg TableModel, then although a complex GUI may warrant separate packages, it is equally arguable that they can all go in the same package. As regards is M, V or C GUI or not, then with this definiation of model, yes they most certainly are all GUI. Although a Swing Model class could be used for another kind of view, it would be a bad idea.
On the other hand, if you mean by model, the business model. Then yes that should be in a different package. The only big question is do you put htat package server side or client side?
Which neatly segues into a discussion about thin vs thick clients
The only Swing-based class in this scheme is the MainWindow, which also implements the ViewReference interface. This interface implements some generic methods for retrieving data from the view and updating the view, and is passed as an argument in the Controller constructor.
So my FlightDataModel is a "business model", holding a reference to the (local or remote) database services. It has nothing to do with JTable or the TableModel. Instead, the tableModel is considered as part of the Swing-based view, and actually is added as an observer of the FlightDataModel (which extends Observable).
So i think we agree that my model and controller classes are not part of the GUI. In my opinion, they belong to the client and certainly not to the server. The (local or remote) FlightDataServices could be considered as a middleware layer, but because we have no separate middle-tier, it becomes part of the client. Greetz, Klaas [ August 26, 2004: Message edited by: Klaas van Gelder ]