DDD y repositorios asíncronos

Question

Estamos trabajando en un cliente enriquecido (escrito en Flex) que está conectado a un backend de Java, utilizando RMI y JMS. Estaba pensando en implementar el cliente de forma DDD para que tenga repositorios para las operaciones de CRUD en los objetos del dominio.

Sin embargo, el problema es que todas las comunicaciones de back-end ocurren de forma asíncrona y no hay forma de forzar al cliente a esperar para continuar hasta que haya recibido una respuesta. Eso significa que, en un nivel bajo, puedo llamar a un método en un Objeto Remoto y obtengo un AsyncToken como valor de retorno. Luego puedo escuchar los eventos en el asynctoken para ver si la llamada ha pasado o ha fallado. Sin embargo, esto rompe la idea principal detrás de un repositorio, para ocultar los detalles técnicos del cliente.

Podría haber 2 opciones, supongo:

1. haga que los métodos del repositorio devuelvan el asynctoken, lo que me parece una solución desordenada
2. haga que los métodos devuelvan una colección vacía (para un findAll por ejemplo) que se llenará cuando se reciba la respuesta.

Ambos tienen ventajas y desventajas y me gustaría recibir algunas sugerencias de ustedes.

(¿Llevando esto más lejos, cuáles serían las buenas estrategias de almacenamiento en caché? Dependiendo de la situación, no quiero que el repositorio llame al servidor cada vez que solicite todas las entidades. ¿Cómo afectaría eso la firma de los métodos en el repositorio.)

Answer 1

Flex y Flash Remoting son inherentemente asíncronos, por lo que luchar contra ese paradigma te dará un montón de problemas. Nuestros delegados de servicio devuelven AsyncToken desde todos los métodos y nunca hemos tenido un problema con él.

Si desea asegurarse de que la aplicación no genere una nueva vista o realice alguna otra lógica hasta que el resultado / error vuelva a aparecer, podría hacer lo siguiente:

1. Adjunte un detector de eventos para un evento personalizado que invocará su " resultado / código de falla "
2. Haz la llamada asíncrona
3. Manejar el resultado / falla
4. Envíe el evento personalizado para activar su escucha desde # 1

Ten en cuenta que esto va a llevar a un montón de códigos de placa de incidencias molestos cada vez que hagas una llamada asíncrona. Consideraría con mucho cuidado si realmente necesita una ruta de ejecución síncrona.

Answer 2

Recomendaría devolver un AsyncToken ya que devolver una colección vacía se siente mal.

En el caso de que estés devolviendo datos de un caché, devuelve un CompletedAsyncToken (: AsyncToken) que activa automáticamente el evento COMPLETE con los datos cada vez que el evento COMPLETE se suscribe (y luego elimina el controlador).

public class CompleteAsyncToken : AsyncToken
{
    public function CompleteAsyncToken(data : Object)
    {
        super(data);
    }

    public override addEventListener(type:String, listener:Function, useCapture:Boolean = false, priority:int = 0, useWeakReference:Boolean = false) : void
    {
        super.addEventListener(type, listener, useCapture, priority, useWeakReference);

        if (type == Event.COMPLETE)
        {
            // Don't just execute listener as EventDispatcher is not that simple
            super.dispatchCompleteEvent();
            super.removeEventListener(type, listener);
        }
    }

Answer 3

Una estrategia sería crear una fachada frente al repositorio. Su cliente realizará llamadas asíncronas a la fachada que, a su vez, realizará una llamada sincrónica a su repositorio. Esto permitirá que su repositorio continúe trabajando de manera sincrónica, mientras que la fachada gestiona los aspectos asíncronos de su llamada.