title: Java Swing Application with a JTree - MVC Design: Where to position a TreeModel object architecturally?
body: <p>Please excuse the verbosity of this question, as in writing it I am attempting to think through my design problem!</p>
  
  <p>I have inherited a Swing application which requires re-architecting into an RMI application. The customer requires the Swing GUI to run locally and communicate via RMI to a remote Server process, which encompasses a Controller class which directs calls to sections of business logic and back end database persistence when stimulated by EventListeners, which bridge the gap between the Swing Client and the Controller.</p>
  
  <p>I am to implement an MVC design to allow for new Views to be developed for use with the server.</p>
  
  <p>Currently, the Swing Client GUI contains a JTree which is populated using a DefaultTreeModel. This Model is constructed using DefaultMutableTreeNode objects which are populated with Business Object state via a BusinessObject mapper that sits between these objects and my Data Source.</p>
  
  <p>I have no problem understanding how the Client and the TreeModel are linked: I have established a TreeModelListener to look out for changes to the TreeModel. If the TreeModel object changes, I redraw the JTree by calling its treeHasChanged() method.</p>
  
  <p>However, I am having a headache trying to picture what process would stimulate the TreeModel, so that its contents are repopulated with the latest data in the database, which would in turn invoke my TreeModelListener to update my GUI's Jtree. Who should "own" the TreeModel? Should it be a Class in the model which makes up a piece of the Controller's state? Should the Actions in the Controller by the GUI's EventListeners make a hard call to run a routine to refresh the TreeModel?</p>
  
  <p>Or alternatively is the TreeModel an extension of the GUI Widget, in which case it is a View component? If so, what would be the proper manner in which to invoke a refresh of the state of this object?</p>
  
  <p>I should probably note that I have been thinking in terms of Observers and Listeners in recent days, so I am probably guilty of trying to invoke behaviour to occur off the back of an observer firing.</p>
  
  <p>Yours, very confused!</p>