Что делает модель в MVC и как она связана с SwingWorker?

Question

Я много читал о Java, Swing, MVC и SwingWorker, но я совершенно запутался в роли Модели в MVC.

Я создаю приложение с двумя кнопками:

1. выбрать файл
2. читать файл

Существует также текстовое поле, используемое для регистрации.

Что я сейчас делаю:

1. Вид содержит виджеты, но без логики
2. Методы actionPerformed () кнопки вызывают метод на контроллере
3. Контроллер будет извлекать необходимые данные (включая отображение OptionPane.showOpenDialog ()) для получения файла
4. Ссылка на файл хранится в модели.
5. Модель уведомляет (PropertyChangeSupport, шаблон Observer) о представлении нового файла.
6. Просмотр включает кнопку «Чтение файла»

Мой первый вопрос : нужно ли сохранять состояние в модели? То есть информация, относящаяся к последовательности операций: сначала файл должен быть выбран, прежде чем его можно будет прочитать. И тогда моя Модель станет конечным автоматом.

Мой второй вопрос : правильно ли, что я позволил контроллеру показать OptionPane?

Тогда начинается самое интересное. Пользователь нажимает кнопку «прочитать файл». Я делаю более или менее так же, как с кнопкой «Выбрать файл». View вызывает Controller, но Controller использует SwingWorker для чтения файла, так как это не должно быть сделано в EDT. SwingWorker публикует промежуточные сообщения журнала, которые добавляются в текстовое поле посредством ссылки на метод View (метод SwingWorker.process ()). Контроллер прослушивает изменения свойств «состояния» из SwingWorker. Когда 'state' равен 'DONE', тогда контроллер вызывает функцию 'get ()'. Если все в порядке, результаты устанавливаются в модели. Если нет, исключения обрабатываются.

Мой третий и самый важный вопрос : не должна ли Модель читать файлы ?! Весь смысл MVC заключается в разделении интересов со всеми преимуществами (тестируемость и т. Д.). Что делать, если я хотел новый вид (например, CLI)? Тогда моя модель теперь будет только моделью данных. Он не имеет понятия о том, как читать файл! А как насчет вопросов с потоками?

Надеюсь, вы можете дать мне хороший совет. В Интернете существует множество примеров, касающихся SwingWorker, MVC и т. Д. Но моя проблема не в том, как их кодировать, а в том, как их проектировать.

Answer 1

Я думаю, вы в значительной степени на ходу. Чтобы ответить на ваши вопросы по одному:

1. я должен хранить состояние в модели? да, вы можете и должны сохранять состояние в вашей модели - модель - это состояние и поведение, которые изменяют это состояние.

2. это правильно, что я позволил контроллеру показать OptionPane? да - дизайн приложения (логический поток) решает, откуда поступает файл - модель, конечно, не заботится о том, как получить имя файла для чтения, просто что она получает имя файла. поток является доменом контроллера.

3. модель не должна читать файлы? да еще раз, чтение файла является частью модели. Несмотря на то, что контроллер вызывает работника качания, работник качания концептуально является частью модели, по крайней мере, основной логикой, выполняемой работником качания. В идеале вся логика загрузки файла заключается в модельных классах. Контроллер затем может организовать вызов этого с помощью рабочего качания. Контроллер решает, что загрузка файла должна происходить в фоновом потоке, и дает указание модели загрузить файл из фона. Рабочий колебания контроллера получает события прогресса загрузки от модели и обрабатывает их, вызывая publish (), а затем process () обновляет пользовательский интерфейс.

В принципе, вы должны иметь возможность переписать все приложение как консольное приложение без необходимости менять модель. Естественно, представление меняется, но это потому, что теперь он должен представлять модель, используя стандартный вывод, а не Swing. Самые большие изменения происходят в контроллере - поток приложения будет другим (выбор файла происходит из аргументов программы), контроллер больше не слушает нажатия кнопок для прямого потока, но либо имеет фиксированный поток, либо взаимодействует с пользователем через stdin. И модель потоков в контроллере отличается - не нужно беспокоиться о EDT, поэтому не нужно качать работника.

Итак, вы видите, что модель заботится о состоянии и изменяет это состояние, представление заботится о представлении состояния, а контроллер делает все остальное, в частности, подключает модель к представлению.