In MVC, what does the model do and what is the relationship with SwingWorker?

Question

I read a lot about Java, Swing, MVC, and SwingWorker, but I am completely confused as a model in MVC.

I am creating an application with two buttons:

• select File
• read file

There is also a text box used for logging.

What I am doing now:

• The view contains widgets but no logic
• The buttonPerformed () method calls the method on the controller
• The controller will receive the required data (including the display of OptionPane.showOpenDialog ()) to obtain the file
• The link to the file is stored in the model.
• The model notifies (PropertyChangeSupport, observer pattern) the presentation of the new file.
• View allows the "read file" button

My first question is : should I store state in the model? That is, information related to the sequence of operations: you must first select a file before it can be read. So, my model will become the ultimate machine.

My second question is : Am I correctly allowing the controller to show OptionPane?

Then the fun begins. The user clicks the "read file" button. I do more or less the same thing as with the select file button. View calls the controller, but the controller uses SwingWorker to read the file, as this should not be done in the EDT. SwingWorker publishes intermediate registration messages that are added to the text field using a link to the View method (SwingWorker.process ()). The controller listens for state property changes from SwingWorker. When the "state" is "DONE", the controller calls the function "get ()". If everything is in order, the results are set in the model. If not, exceptions are handled.

My third and most important question is : should the model do the reading? The whole point of MVC is the separation of problems, with all the benefits (testability, etc.). What if I need a new view (e.g. CLI)? Then my model will now be just a data model. He does not know how to read the file! What about threading issues?

Hope you can give me some good advice. There are many examples on the Internet about SwingWorker, MVC, etc. But my problem is not how to code against them, but how to develop.

Answer 1

I think you're pretty much on the go. To answer your questions one by one:

1. Should I keep the state in the model? Yes, you can and should save the state in your model - the model is a state and behavior that changes this state.

2. Am I correctly allowing the controller to display OptionPane? yes - the application design (logical stream) decides where the file comes from - the models, of course, no matter how the file name is received for reading, just so that it gets the file name. the stream is the domain of the controller.

3. should the model read the file? yes again, reading the file is part of the model. Although the controller calls the swing worker, the swing worker is conceptually part of the model, at least the basic logic performed by the swing worker. Ideally, the entire logic of file loading lives in model classes. Then the controller can arrange for this call using a working swing. A controller is one who decides that the file should be downloaded in the background thread and instructs the model to download the file from the background. The controller dispatcher worker receives download execution events from the model and processes them by calling publish (), and then process () updates the user interface.

Basically, you should be able to rewrite the entire application as a console application without changing the model. Naturally, the view is changing, but it is because now it must present the model using stdout, not Swing. The biggest changes occur in the controller - the application stream will be different (the file selection comes from the program arguments), the controller no longer listens for button presses for the direct stream, but has a fixed stream or interacts with the user via stdin. And the thread model in the controller is different - no need to worry about EDT, so there is no need for a swing.

So, you see that the model takes care of the state and changes of this state, the view takes care of the state representation, and the controller does the rest, in particular, connecting the model to the view.