client design

Hi. I'm a bit stuck on my client-side design and would be extremely grateful if someone could help me out. Here's what I have: a connection interface (providing all public db.Data methods) that is implemented by two classes, remote and local (connect to a server and a data layer respectively). A client facade, containing the methods 'getConnection', 'search' and 'book'. A client gui class that creates all swing components, implements listeners, handles events, etc. From what I've read in earlier articles here at the ranch, one should use mvc to implement the gui. Does this mean just using swing components that already use mvc (jtable, etc.) or actually implement the mvc pattern to your whole client gui? If the latter: how would you do this? My current class, I can see, is now far too big and should be broken up. Is it a good idea to create a separate controller class to handle events? I suspect this alone would not make it a mvc pattern... Final question: Is there any point in introducing a ConnectionFactory when I've designed like described above? Definitely last question: I'm not too familiar with patters. Is my ClientFacade a facade or a proxy...? Appreciate any comments. Cheers. Amund

Last two question answer : YES Yes you should also split that GUI into two classes one that only has GUI, the other for a controller. Your Facade is your Data Model. the GUI the view, and your new controller, well the controller. hence MVC. Do a search, actually a couple of days ago we had a thread that went into this whole discussion on MVC. Mark

Thank you, Mark. Would it be an idea to split the client mvc design into two: one for the actual client and another for the table (contained within the client ui)? Or is that an overkill? There seems to be a some table-specific logic I'm not sure what to do with... The dilemma: keeping the two methods createTable() and updateTable() in the View, goes against the principle of keeping it "view only" (no logic). However, by putting these methods into the Controller, would mean that the View would have to access the Controller, not only the other way around. This would also go against the mvc pattern, wouldn't it? Any opinion on this, anyone? Thank you. Amund [ February 21, 2002: Message edited by: Amund Frislie ]

Mark, I just read this (obviously I'm a little behind)and had a question. What is the controller class you mention in the quote below? As I currently understand it a Swing component contains the view and controller and allows you to have a separate model class. Essentially, the class that extends AbstractTableModel is the Model and the JTable is the View and Controller. Are you saying that you actually had a separate Controller class? I haven't seen that sort of architecture yet, would you please elaborate? Thanks!

Originally posted by Mark Spritzler: The AbstractTableModel is MVC to the Table. I have a separate JPanel for my JTable, and also have extended AbstractTableModel. In my JPanel, I added a method that returns a reference to the JTable, that way the one controller can ask for it, and then reset it's model with setModel. Mark

The other controller is the controller for the entire Client GUI. and actually the JTable is not the controller and the view, it is just the view. The JTableModel is the model. I have my ClientGUI class that only has the view, meaning the display. It also has some hook methods to hook controller methods to events/actions. Mark

Burk Hufnagel
Ranch Hand

Joined: Oct 01, 2001
Posts: 814

3

posted Mar 21, 2002 19:37:00

0

Mark, Let me see if I understand... You have some kind of a Controller class that accepts events from the ComboBoxes, TextField and Buttons then decides what to do about it. Example: The user selects a Departure city and presses the Search button. 1) The button notifies the Controller of the action 2) The controller to queries the db.db file (via another object that could be connected to a local db.db file or a remote one) then updates the TableModel 3) The TableModel fires an event telling the JTable to update its contents. 4) The JTable clears its view and befreshes itself using the new data in the TableModel. 5) Whew! Is that it, or am I waaay off base? BTW I expect that you could use anonymous classes to listen for events and send them to the Controller, or implement Action object to do the same thing. Thanks for explaining this to me! Burk

Originally posted by Mark Spritzler: The other controller is the controller for the entire Client GUI. and actually the JTable is not the controller and the view, it is just the view. The JTableModel is the model. I have my ClientGUI class that only has the view, meaning the display. It also has some hook methods to hook controller methods to events/actions. Mark

Burk, take a deep breath, that was a doosie. Yes that is about right, and yes there are other design patterns to implement your MVC to hook actions to the GUI. In the case of Anonymous Inner Classes in the GUI, I think that way couples the Action, or the Controller too much into the GUI class. It is ok for the Controller to couple itself to the GUI class. Meaning the Controller should always know about the GUI class, whereas the GUI really knows nothing about the Controller class, just that the controller class told the GUI, "Hey tell me when something happens!" Mark

I use the anonymous inner classes in the controller to hook into the GUI. You could have the controller implement ActionListerner and send itself to the GUI, but then you will have an ActionPerformed in the controller with a case statement that checks to see what Action actually occured, then call a separate method for each Action. With anonymous Innerclasses, each action will have it's own ActionListener/ActionPerformed, that calls the method that needs to be run. Both work, and it can come down to symantics. I just think it is easier to read without a case/nested ifs statement. Mark