La mejor manera de separar de Empresas de la presentación lógica?

Question

Quiero crear un juego que va a trabajar tanto a nivel local y en línea.

Lo primero que pensé fue crear una interfaz que tendría todos los métodos que serán necesarios por la interfaz gráfica de usuario para la lógica de negocio y luego tener una implementación de red y una aplicación local.

Esto funciona bien para los mensajes de petición-respuesta. Pero ¿qué pasa con los mensajes que envía el servidor, donde tengo que actualizar algunos componentes GUI (es decir JLabels)?

Mi primera solución a esto fue para poner en práctica los oyentes, donde cada cambio en la aplicación se dispare un evento. La interfaz gráfica de usuario registraría y el cambio de componentes adecuadamente. Sin embargo, las llamadas a disparar eventos en la lógica de negocio se ve un poco mal.

¿Estoy en el camino correcto? Porque yo creo que no soy. ¿Alguna sugerencia?

Gracias.

NOTA:. El cliente es una sencilla interfaz gráfica de usuario Java Swing

Answer 1

Lo que usted ha descrito servirá el objetivo de mantener el modelo independiente de temas de presentación, que es una buena cosa. Esto también le ayudará durante el diseño, desarrollo y mantenimiento del modelo, porque se puede escribir pruebas unitarias sobre la base de que ciertos cambios en el modelo deben disparar eventos específicos, sin tener que preocuparse acerca de lo que podría parecer en una pantalla.

Y, por supuesto, le libera de tener diferentes diseños de interfaz gráfica de usuario para diferentes entornos.

La clave es que los eventos deben estar sobre los cambios en el estado del modelo, y no sobre destinadas acciones / representaciones a nivel de presentación. Permitir que el acuerdo con la capa de presentación si / cómo responder a un evento de modelo.

Answer 2

Voy a admitir que hago desarrollo web, por lo que no tienen mucha experiencia con Swing.

Pero siempre he pensado que la forma en que me acerco sería romper la aplicación en paquetes / vista, / modelo y / controlador. Las relaciones serían unidireccional: / controlador sabría de ambos / modelo y / vista, pero tampoco importarían las clases de controlador / o entre sí

.

componentes de la capa El / vista nunca serían JFrames; ellos siempre estarían JPanel u otro recipiente adecuado que podría estar compuesto juntos en JFrames según sea necesario. Cada uno tendría referencias a las interfaces de escucha, que se inicia en los constructores, y aplazando a estos para el manejo de eventos:

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

Esta disposición funciona bien con la inyección de dependencia, porque ahora el controlador puede optar por utilizar una aplicación local o remota de esa interfaz Listener, cambiando el comportamiento de una manera que no afecta al cliente en absoluto.

Voy a admitir que nunca he seguido todo el camino a través.

La gente de primavera tienen un módulo de cliente oscilación rico, pero parece haber caído en desgracia. Parece que han decidido que una dirección BlazeDS es una mejor opción para los clientes ricos. Pero tal vez usted puede recoger algunas ideas de diseño de su enfoque.