Лучший способ отделить бизнес от логики презентации?
-
23-08-2019 - |
Вопрос
Я хочу создать игру, которая будет работать как локально, так и онлайн.
Моей первой мыслью было создать интерфейс, который имел бы все методы, необходимые графическому интерфейсу для бизнес-логики, а затем имел сетевую реализацию и локальную реализацию.
Это отлично работает для сообщений типа запрос-ответ.Но как насчет сообщений, которые отправляет сервер, где я должен обновить некоторые компоненты графического интерфейса (т. е.JLabels)?
Моим первым решением для этого было внедрение прослушивателей, где каждое изменение в реализации запускает событие.Графический интерфейс будет регистрироваться и соответствующим образом изменять свои компоненты.Однако вызовы событий запуска в бизнес-логике выглядят немного неправильно.
На правильном ли я пути?Потому что я думаю, что это не так.Есть какие-нибудь предложения?
Спасибо.
ПРИМЕЧАНИЕ:Клиент представляет собой простой графический интерфейс Java Swing.
Решение
То, что вы описали, послужит цели сохранения независимости модели от проблем с презентацией, и это хорошо.Это также поможет вам при проектировании, разработке и обслуживании модели, поскольку вы можете писать модульные тесты на основе того, что определенные изменения в модели должны вызывать определенные события, не беспокоясь о том, как это может выглядеть на экране.
И, конечно же, это освобождает вас от необходимости создавать разные графические интерфейсы для разных сред.
Ключевым моментом является то, что события должны касаться изменений в состоянии модели, и не о предполагаемых действиях / представлениях на уровне презентации.Пусть уровень представления решает, следует ли / как реагировать на событие модели.
Другие советы
Я признаю, что занимаюсь веб-разработкой, поэтому у меня не так уж много опыта работы со Swing.
Но я всегда думал, что мой подход к этому заключался бы в том, чтобы разбить приложение на пакеты / view, /model и / controller.Отношения были бы однонаправленными:/controller знал бы как о / model, так и о / view, но ни один из них не импортировал бы какие-либо классы из / controller или друг из друга.
Компоненты слоя / view никогда не будут JFrames;это всегда будет JPanel или другой подходящий контейнер, который при необходимости можно было бы скомпоновать в JFrames.Каждый из них будет иметь ссылки на интерфейсы прослушивателя, инициализированные в конструкторах, и будет ссылаться на них для обработки событий:
public class ExamplePanel extends JPanel implements ActionListener
{
private JButton button;
private ActionListener buttonListener;
public ExamplePanel(ActionListener buttonListener)
{
this.button = new JButton("Do Something");
this.buttonListener = buttonListener;
this.button.addListener(this.buttonListener);
}
public void actionPerformed(ActionEvent e)
{
this.buttonListener.actionPerformed(e);
}
}
Такая схема хорошо работает с внедрением зависимостей, потому что теперь контроллер может выбрать использование локальной или удаленной реализации этого интерфейса прослушивателя, изменяя поведение таким образом, чтобы это вообще не влияло на клиента.
Я признаю, что никогда не следил за этим до конца.
У людей из Spring есть богатый клиентский модуль Swing, но, похоже, он впал в немилость.Похоже, они решили, что направление BlazeDS - лучший выбор для богатых клиентов.Но, возможно, вы сможете почерпнуть некоторые дизайнерские идеи из их подхода.