I’m writing a Swing application, and further to my previous question, have settled on using the Model-View-Presenter pattern to separate the user interface from the business logic.
When my application starts up, it executes the following code:
Model model = new BasicModel(); Presenter presenter = new Presenter(model); View view = new SwingView(presenter); presenter.setView(view); presenter.init();
which creates the user interface. Events are generated by the View, and delegated to the Presenter. The Presenter then manipulates the Model and updates the View accordingly.
In order to handle some events, I need to obtain further information from the user. In the case of these events, I believe it is appropriate for the Swing view to spawn a new JDialog window.
One line of thinking makes me feel this might be appropriate code in the orignal Presenter:
public void handlePreferences() { Preferences prefs = view.getPreferences(); model.setPreferences(prefs); }
That is, the contents of each JDialog should represent a distinct object that should be retrieved from the View and updated in the Model. However, this leaves the question: do I create a new Model to represent the Preferences object and a new Presenter for event handling in that JDialog?
It seems to me that creating a new Presenter and Model internal to the original View forces me to do a lot of work that would be harder to port if I wanted to change the UI to use JSF, for example.
Please feel free to add comments for clarification.
Although it is not uncommon to have ‘nested’ design patterns it is not necessary in your case. Drawing on the other answers:
Model
– Contains all the real data, variables, objects
– knows how to set its stored data values to the new values
– responds to orders (method calls)
– has method setPreferences(value1,value2,value3…);
View
– is the IO for the application, just output and input
– it can only work on its self, on its state
– it maintains local variables and objects, eg. it has JButtons, JMenus, int counters …
– it is knows how to inform the Presenter of State Change
– its state is visible to the Presenter, or revealed by method call
– responds to orders (method calls)
– knows how to get preferences from the user
– has method askForPrefs();
– has method getPrefState();
Presenter
– Responds to state changes
– does all the deciding, it tells the other objects what to do (not how to do it)
– knows when preferences are needed
– knows where to get new preferences and where to put them
– has method newPrefsAvailable();
Presenter – checks the Model, determines new preferences are required
Presenter – this.myView.askForPrefs(); //tells view to ask user for pref values
View.askForPrefs – pops up a JDialog box, retVals stored in the view as a state change
View – this.myPresenter.newPrefsAvailable();
Presenter – responds with this.myModel.setPreferences (this.myView.getPrefState());
Model.setPreferences – changes the stored values to View.getPrefState()
Presenter – checks the Model – determines preferences are good
Presenter – continues on
The JDialog is treated as just an extension of the View,it is a member of the View just like a JButton would be. The model has the authoritative actual preference values, and the view has local variables that represent the state of the JDialog.