Лучший способ отделить бизнес от логики презентации?

Я хочу создать игру, которая будет работать как локально, так и онлайн.

Моя первая мысль состояла в том, чтобы создать интерфейс, который будет иметь все методы, которые потребуются графическому интерфейсу для бизнес-логики, а затем иметь сетевую реализацию и локальную реализацию.

Это отлично работает для сообщений типа запрос-ответ. Но как насчет сообщений, которые отправляет сервер, в которых мне нужно обновить некоторые компоненты графического интерфейса (например, JLabels)?

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

Я на правильном пути? Потому что я думаю, что нет. Какие-либо предложения?

Спасибо.

ПРИМЕЧАНИЕ. Клиент представляет собой простой графический интерфейс Java Swing.


java presentation-layer business-logic-layer
person pek    schedule 27.12.2008    source источник

Ответы (2)


arrow_upward
6
arrow_downward

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

И, конечно же, это освобождает вас от необходимости иметь разные дизайны графического интерфейса для разных сред.

Суть в том, что события должны быть об изменениях в состоянии модели, а не о предполагаемых действиях/представлениях на уровне представления. Пусть уровень представления решает, следует ли и как реагировать на событие модели.

person joel.neely    schedule 27.12.2008
comment
Итак, я на правильном пути с реализацией слушателей? А как насчет этого печально известного MVC, о котором я постоянно слышу? Я точно не знаю, как это реализовать, но я думаю, что должен спросить, прежде чем делать это. - person pek; 27.12.2008
comment
я согласен с Джоэлом - это mvc ... ваш взгляд слушает модель и обновляет себя. Ваша модель — это бизнес-логика. Остальная часть вашего графического интерфейса (меню и т. д.) взаимодействует (или является) с частью контроллера и взаимодействует с моделью, чтобы манипулировать ею. Любой элемент можно заменить независимо от других. - person frankodwyer; 27.12.2008
comment
Хммм..не думал об этом.. ;) - person pek; 27.12.2008

arrow_upward
1
arrow_downward

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

Но я всегда думал, что я бы разбил приложение на пакеты /view, /model и /controller. Отношения будут однонаправленными: /controller будет знать и о /model, и о /view, но ни один из них не будет импортировать какие-либо классы из /controller или друг друга.

Компоненты слоя /view никогда не будут JFrames; они всегда будут JPanel или другим подходящим контейнером, который может быть объединен в JFrames по мере необходимости. Каждый из них будет иметь ссылки на интерфейсы Listener, инициализированные в конструкторах, и будет полагаться на них для обработки событий:

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 — лучший выбор для богатых клиентов. Но, возможно, вы сможете почерпнуть некоторые дизайнерские идеи из их подхода.

person duffymo    schedule 27.12.2008