DDD e repository asincroni

Question

Stiamo lavorando su un rich client (scritto in Flex) collegato a un back-end Java, utilizzando sia RMI che JMS. Stavo pensando di implementare il client in modo DDD in modo che abbia repository per le operazioni CRUD sugli oggetti dominio.

Il problema è tuttavia che tutte le comunicazioni back-end avvengono in modo asincrono e non c'è modo per forzare il client in attesa di continuare fino a quando non riceve una risposta. Ciò significa che, a un livello basso, posso chiamare un metodo su un oggetto remoto e ottenere un AsyncToken come valore di ritorno. Posso quindi ascoltare gli eventi in asincrono per vedere se la chiamata è passata o è fallita. Questo tuttavia rompe l'idea principale dietro un repository, per nascondere i dettagli tecnici al client.

Potrebbero esserci 2 opzioni immagino:

1. i metodi sul repository restituiscono l'asynctoken, che mi sembra una soluzione disordinata
2. i metodi restituiscono una raccolta vuota (ad esempio per findAll) che verrà riempita quando viene ricevuta la risposta.

Entrambi hanno pro e contro e vorrei ricevere un contributo da voi ragazzi.

(prendendo questo oltre, quali sarebbero le buone strategie di memorizzazione nella cache? A seconda della situazione, non voglio che il repository chiami il server ogni volta che richiedo tutte le entità da esso. In che modo ciò influenzerebbe la firma dei metodi su il repository.)

Answer 1

Flex e Flash Remoting è intrinsecamente asincrono, quindi combattere contro quel paradigma ti darà un sacco di problemi. I nostri delegati del servizio restituiscono AsyncToken da ogni metodo e non abbiamo mai avuto problemi con esso.

Se vuoi assicurarti che l'applicazione non esegua il rendering di una nuova vista o esegua qualche altra logica fino a quando non viene restituito il risultato / errore, puoi fare quanto segue:

1. Allega un listener di eventi per un evento personalizzato che invocherà il tuo " post risultato / codice di errore "
2. Effettua la chiamata asincrona
3. Gestisci il risultato / errore
4. Invia l'evento personalizzato per attivare il tuo ascoltatore dal numero 1

Tieni presente che questo porterà a un sacco di fastidioso codice della piastra di cottura ogni volta che effettui una chiamata asincrona. Considererei attentamente se hai davvero bisogno di un percorso di esecuzione sincrono.

Answer 2

Vorrei raccomandare di restituire un AsyncToken poiché restituire una raccolta vuota sembra sbagliato.

Nel caso in cui si stiano restituendo dati da una cache, restituire un CompletedAsyncToken (: AsyncToken) che genera automaticamente l'evento COMPLETE con i dati ogni volta che l'evento COMPLETE viene sottoscritto (e quindi rimosso il gestore).

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

Uno straegy sarebbe quello di creare una facciata di fronte al repository. Il tuo client effettuerà chiamate asincrone alla facciata che a sua volta effettua una chiamata sincrona al tuo repository. Ciò consentirà al repository di continuare a lavorare in modo sincrono mentre la facciata gestisce gli aspetti asincroni della chiamata.