La meilleure façon de séparer des affaires de présentation logique?

Question

Je veux créer un jeu qui fonctionnera à la fois localement et en ligne.

Ma première pensée était de créer une interface qui aurait toutes les méthodes qui seront nécessaires par l'interface graphique pour la logique métier et une mise en œuvre du réseau et une mise en œuvre locale.

Cela fonctionne bien pour les messages de demande-réponse. Mais qu'en est-messages que le serveur envoie, où je dois mettre à jour certains composants de l'interface graphique (à savoir les JLabels)?

Ma première solution à c'était à mettre en œuvre les auditeurs, où chaque changement de la mise en œuvre se déclenche un événement. L'interface graphique s'enregistrer et modifier les composants de manière appropriée. Cependant, les appels à déclencher des événements dans la logique d'affaires semble un peu mal.

Suis-je dans la bonne voie? Parce que je pense que je ne suis pas. Toutes les suggestions?

Merci.

NOTE:. Le client est un simple GUI Java Swing

Answer 1

Ce que vous avez décrit servira l'objectif de maintenir l'indépendance du modèle des questions de présentation, ce qui est une bonne chose. Cela vous aidera également lors de la conception, le développement et l'entretien du modèle, parce que vous pouvez écrire des tests unitaires sur la base que certains changements dans le modèle devraient déclencher des événements spécifiques, sans se soucier de ce qui pourrait ressembler à un écran.

Et, bien sûr, il vous permet de libérer d'avoir des conceptions différentes de l'interface graphique pour différents environnements.

La clé est que les événements doivent être des changements dans l'état du modèle, et pas sur les actions envisagées / représentations au niveau de la présentation. Laissez la couche de présentation traitent si / comment répondre à un événement de modèle.

Answer 2

Je dois admettre que je fais du développement web, donc je n'ai pas beaucoup d'expérience avec Swing.

Mais je l'ai toujours pensé que la façon dont j'approche serait de briser l'application en paquets / vue, / modèle et / contrôleur. Les relations seraient unidirectionnel: / contrôleur connaîtrait à la fois / modèle et / vue, mais ni importeraient toutes les classes de / contrôleur ou l'autre

.

composants de la couche La / vue ne seraient jamais JFrames; ils avaient toujours être JPanel ou un autre récipient approprié qui pourrait être composé ensemble dans JFrames au besoin. Chacun d'eux des références à des interfaces, Listener initialisés dans les constructeurs, et qui différerait à ces dernières pour la gestion des événements:

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);
    }
}

Cet arrangement fonctionne bien avec l'injection de dépendance, parce que maintenant le contrôleur peut choisir d'utiliser une implémentation locale ou à distance de cette interface Listener, en changeant le comportement d'une manière qui ne touche pas le client du tout.

Je dois admettre que je ne l'ai jamais suivi tout le chemin à travers.

Les gens de printemps ont un module client riche Swing, mais il semble être tombé en disgrâce. On dirait qu'ils ont décidé qu'une direction BlazeDS est un meilleur choix pour les clients riches. Mais peut-être vous pouvez glaner quelques idées de conception de leur approche.