Я не хочу говорить что-то такое невообразимое, но MVC работает - это не главное, но оно может начать вас организовывать.
РЕДАКТИРОВАТЬ: При поиске по полу-связанной теме, я наткнулся на этот , который имеет схожие с моими идеями, но более подробно.
С точки зрения GWT это означает, что вы должны подумать о том, чтобы просто расположить компоненты GUI в одном классе, поместить всю обработку событий в секунду и отделить объекты объектной модели от двух других.
Один из способов сделать это состоит в том, чтобы сделать большинство или все элементы управления открытыми членами GUI. Это звучит неубедительно, но их использование заключено в контроллере, поэтому вы не имеете неконтролируемого доступа - на самом деле ваш доступ яснее / лучше определен, чем если бы все ваши члены были частными, но ваш код представления был объединен с контроллером.
Особые хитрости:
Пусть слушатели будут в своем классе. Вы можете часто использовать их - другими словами, избегать анонимных внутренних классов. Иногда я создаю класс слушателя и создаю новый экземпляр для каждой кнопки / элемента управления, который должен иметь аналогичный эффект при нажатии. Если мне нужно, чтобы он работал немного по-другому для данной кнопки, я передам кое-что в конструктор «специальных» обработчиков, чтобы они знали, что они действуют немного по-другому. При необходимости вы также можете создавать различные подклассы обработчиков - я просто говорю, что не забывайте, что обработчики событий - это классы, вы можете использовать наследование и все, что нужно.
Один очень старый трюк с графическим интерфейсом, который я изучил давным-давно, старайтесь не использовать различные мини-обработчики, изменяющие графический интерфейс различными способами, вместо этого все «активные» кнопки и элементы управления устанавливают состояние в вашем графическом интерфейсе, а затем вызывают единственный метод, который применяет это состояние ко всем элементам управления в вашем графическом интерфейсе. Когда вы выходите за рамки обычного графического интерфейса, это может спасти жизнь. Если мне неясно, оставьте комментарий, и я оставлю вам пример.
Листы недвижимости:
Существует особый случай для графического интерфейса - графический интерфейс стиля листа свойств. Я сделал много из них, и они раздражают, как АД. У них, как правило, есть десятки или сотни элементов управления, каждый элемент управления GUI имеет тенденцию быть привязанным к определенному полю в вашей модели, и есть только сотни строк кода копирования и вставки, соединяющих их, каждая группа копируется и вставляется с помощью нескольких элементы изменены - как минимум 3 строки кода на элемент управления (создание элемента управления, копирование значения внутрь и копирование значения).
Я всегда пишу их с помощью «умного» контроллера, который может интеллектуально связывать управление с некоторыми данными без какого-либо уникального кода. Это может быть сложно, и если это ваша проблема, дайте мне знать в комментариях, и я могу дать вам несколько общих советов относительно некоторых хитростей, которые вы можете попробовать. Я прошел путь от минимального рефлексивного решения до полноценного решения на основе XML. Если бы я сделал это снова, я мог бы рассмотреть аннотации на основе.
Пример MVC:
Обратите внимание, это всего лишь пример, есть миллионы способов сделать MVC.
В вашем ГЛАВНОМ:
- Создание экземпляра MyView
- Создание экземпляра MyModel
- Создание экземпляра MyController (myView, myModel)
- myView.setVisible (правда)
в MyView
- вероятно расширяет кадр
- Большинство компонентов являются общедоступными финальными (публичная финальная кнопка b = новая кнопка ())
- Если публичные участники заставляют вас нервничать, используйте getters - тот же самый эффект EXACT, что и для публичных финальных участников с небольшим дополнительным синтаксисом.
- Помните, что вы можете устанавливать конечные элементы в своем конструкторе.
- Может иметь общие методы, такие как reset (), но MyController может быть лучшим местом для этого.
в MyController
- сохраняет ссылки на myView и myModel
- добавляет слушателей в myView, где это необходимо (см. Советы по слушателям выше)
- настраивает myView на основе состояния myModel
- при нажатии кнопки «Готово» копирует состояние из myView в myModel
- уведомляет myModel, что его данные были обновлены, и уничтожает себя.
в MyModel:
Это будет типичный класс модели, он будет содержать вашу бизнес-логику (в основном не используется как часть GUI, это больше похоже на логику GUI в MyController. Контроллер будет стремиться устанавливать значения в вашей бизнес-логике, а затем вызывать некоторый метод как updated (), чтобы заставить некоторую бизнес-логику взять управление. Она не должна ничего знать о GUI - это ваш «чистый» бизнес-класс.
Иногда GUI может вызывать update () или какой-либо другой метод, чтобы инициировать изменение данных и затем перезагружать элементы управления GUI из Модели - это довольно хороший способ интеграции вашей бизнес-логики с вашим GUI без ведома модели про графический интерфейс ...
Кроме того, как я уже говорил выше, я бы вложил больше усилий в MyController, если бы работал с листами свойств только из-за большого количества строк шаблона, которые вы получите, если не разберетесь в этом.
Обратите внимание, что View и Controller почти всегда сопряжены. Вы не можете просто заменить Swing-представление веб-представлением и ожидать, что контроллер останется безмолвным, но модель не должна изменяться для представления или контроллера.