Современный пример Swing MVC + Вопрос [закрыто]

Это большой вопрос. Я поделюсь с вами некоторыми мыслями по этому поводу и посмотрю, что из этого выйдет.

Swing больше Model-> View чем Model-> View-> Controller. Проблема с Model-> View заключается в том, что обычно приложения Swing являются подклассом объекта View, и эти объекты становятся как View, так и контроллером для этого представления, объединенными в одно целое. Сверхурочная работа в больших приложениях приводит к множеству проблем и спагетти-кода.

Вот уже несколько лет я создаю отдельный объект, называемый Контроллером, который не расширяет какие-либо классы пользовательского интерфейса. В этом отношении это старый добрый объект. Этот Контроллер будет отвечать за создание экземпляров компонентов верхнего уровня для представления, подключение слушателей к представлению для ответа пользователю, а также обращение и вызов модели для выполнения работы.

Представление будет подклассом Swing. Представление отвечает за реакцию на события мыши, события клавиатуры и т. Д. Любые события, специфичные для Swing, обрабатываются в представлении. Он также предоставит высокоуровневые методы для обновления представления, которые контроллер будет использовать для обратного вызова для обновления пользовательского интерфейса. Классические модели качелей также являются частью View, потому что ваш выбор компонентов очень сильно зависит от моделей, которые вы будете использовать.Представление также отвечает за отправку событий высокого уровня в Контроллер, а Контроллер отвечает за реагирование на эти события высокого уровня. Этими событиями могут быть UserEvent.ADD, UserEvent.EDIT, AuthenticationEvent.LOG_IN, AuthenticationEvent.LOG_OUT и т. Д. Эти события являются событиями приложения и больше похожи на то, что может распознать менеджер продукта. Контроллер не реагирует на Mouse, ChangListener и т. Д. Я фактически создал для них свою собственную структуру EventDispatch и Event, потому что Swing очень сложно расширить и эффективно использовать. Представление работает примерно так:

public void mouseClicked( MouseEvent evt ) {
   User u = getUserAt( evt.getPoint() );
   dispatch( new UserEvent( UserEvent.EDIT, u ) );
}

В моем контроллере у меня есть простые методы, привязанные к этим событиям. Вот пример одного из них:

@EventCallback( command = "exit" )
public void exit( AppEvent evt ) {
    onExit();
}

@EventCallback(command = "help.about")
public void showAbout(AppEvent evt ) {
    audioFinderFrame.showAboutDialog(engine.getLicenseInfo());
}

@EventCallback( command = MediaSourceEvent.START_REFRESH )
public void refreshStarted(final MediaSourceEvent event) {
   if( frame != null ) frame.refreshMediaSource( event.getSource(), true );
}

Аннотации - это расширение, которое мне нужно для быстрого добавления методов прослушивателя событий к источнику EventDisptach. Но дело в том, что каждый метод контроллера вызывается из представления с использованием событий высокого уровня. Это позволяет Контроллеру быть в некоторой степени изолированным от того, как отображается представление. Метод входа в систему контроллера не должен беспокоиться о том, какие компоненты составляют представление. Он просто получает событие и выполняет работу. Контроллер отвечает за поток приложения.

Поскольку система событий отделена от Swing, я повторно использую ее в слоях модели, чтобы модель могла отправлять события обратно в Контроллер, а Контроллер мог передавать эти изменения в UI.

Модель и Контроллер являются объектами POJO. Они понимают события, но это все.Модель - это логика приложения, включая уровень DAO, сервисы, которые могут выполнять фоновые задания, любой уровень сервиса, который общается с сервером, и объекты, которые большинство людей может назвать DTO. Я не прописываю понятие, что DTO должно быть просто простой структурой получателя / установщика. Я допускаю здесь некоторую логику, потому что они - единственное, что плавает между всеми слоями. Поскольку каждый уровень имеет к ним доступ, они предоставляют удобное место для централизации логики, которую каждый уровень может повторно использовать. Представление, Контроллер и Модель могут получить доступ к этим методам, так почему бы не поместить их в объект, который перемещается между ними.

Обычно эта логика ближе к бизнес-логике или логике обслуживания модели. Я очень осторожен при подключении к этим методам более крупных архитектурных систем. Эти методы не будут взаимодействовать с базой данных или вызывать методы на стороне сервера, поэтому они не переносят ссылки на более крупные элементы архитектуры. У них есть все преимущества DTO: легкие, легко конструируемые, низкие зависимости, но при этом сохраняются принципы объектно-ориентированного дизайна: инкапсуляция, повторное использование и скрытие информации.

Я также начал использовать Spring для связывания частей модели с их зависимостями и зависимостями, которые контроллер имеет от модели. Я обнаружил, что эта модель работает очень хорошо, и это намного приятнее, чем не использовать ее. Также приятно иметь доступ к таким технологиям, как шаблоны Spring JDBC и шаблоны JMS, если я использую эти технологии. Но это необязательно.

Я никогда не использую Контроллеры повторно. Контроллеры - это самая специфическая вещь в вашей системе, и общие сведения только усложняют их обслуживание.Общие положения относятся к представлению и модели, потому что это упрощает разработку. Таким образом, шаблоны проектирования, как правило, оказываются на этих сторонах, но редко в контроллере. Контроллеры - это простые вызовы методов туда и обратно.

Я обнаружил, что это значительно упростило и упростило создание пользовательского интерфейса Swing.У меня меньше шансов попасть в бесконечные циклы событий из-за одновременного прослушивания и управления двумя элементами управления. Я также считаю, что проще протестировать и разбить систему на части, потому что большая часть моей логики существует вне досягаемости Swing. Это делает возможным функциональное тестирование без огромного набора инструментов, пытающегося имитировать щелчки мыши и т. Д.

Здесь не так много кода для иллюстрации, извините, но надеюсь, что это поможет.