DDD und Asynchronous Repositorys

Question

Wir arbeiten an einem Rich-Client (geschrieben in Flex), die mit einem Java-Backend verbunden ist, sowohl RMI und JMS verwenden. Ich dachte an den Client in einer DDD Art und Weise der Umsetzung, so dass es Repositorys für die CRUD-Operationen auf den Domänenobjekte hat.

Das Problem ist jedoch, dass all Back-End-Kommunikation erfolgt asynchron und es gibt keine Möglichkeit für mich, um den Client zu zwingen, zu warten, bis fortzusetzen sie eine Antwort erhalten. Das bedeutet, dass auf einem niedrigen Niveau, ich eine Methode auf einem Remote-Objekt aufrufen kann und ich bekomme eine AsyncToken als Rückgabewert. Ich kann dann auf Ereignisse auf dem AsyncToken hören, um zu sehen, ob der Anruf erfolgreich war oder fehlgeschlagen ist. Dies ist jedoch bricht die Hauptidee hinter einem Repository, die technischen Details von dem Client zu verbergen.

Es könnte zwei Optionen, die ich denke:

1. haben die Methoden auf dem Repository geben die AsyncToken, die wie eine schmutzige Lösung erscheint mir
2. haben die Methoden liefern eine leere Sammlung (für eine findAll zum Beispiel), die gefüllt werden erhalten, wenn die Antwort empfangen wird.

Beide haben Vor- und Nachteile, und ich möchte eine Eingabe von euch erhalten.

(dies weiter nehmen, welche Strategien gutes Caching wäre? Dependind auf die Situation, ich das Repository nicht wollen den Server jedes Mal anrufen ich alle Einheiten von ihm verlangen. Wie würde das die Signatur der Methoden beeinflussen auf das Repository.)

Answer 1

Flex und Flash Remoting von Natur aus asynchron gegen dieses Paradigma so kämpfen werden Ihnen eine Menge Ärger geben. Unser Service Delegierten Rückkehr AsyncToken von jeder Methode und wir hatten nie ein Problem mit ihm.

Wenn Sie sicherstellen möchten, dass die Anwendung nicht eine neue Ansicht nicht machen oder eine andere Logik, bis das Ergebnis durchführen / Fehler zurückkommt, könnte man wie folgt vor:

1. Schließen Sie einen Ereignis-Listener für ein individuelles Ereignis, das Ihr „post Ergebnis / Fehlercode“ aufruft
2. Machen Sie den async Anruf
3. Gehen Sie mit dem Ergebnis / Fehler
4. das benutzerdefinierte Ereignis-Dispatch Ihre Zuhörer von # 1
auslösen

Beachten Sie geht dies auf eine Menge von lästigem boilterplate Code führen jedes Mal, wenn einen asynchronen Anruf. Ich würde sehr sorgfältig, ob Sie wirklich einen synchronen Ausführungspfad benötigen.

Answer 2

würde ich empfehlen, ein AsyncToken Rückkehr als Rückkehr nur eine leere Sammlung fühlt sich falsch an.

In dem Fall, dass Sie Daten aus einem Cache zurückkehren, gibt einen CompletedAsyncToken. (: AsyncToken), die automatisch das COMPLETE-Ereignis mit den Daten ausgelöst, wenn das COMPLETE-Ereignis abonniert wird (und dann entfernt, um die Handler)

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

Eine straegy wäre eine Fassade vor dem Repository zu erstellen. Ihr Kunde wird asychronous Anrufe an die Fassade machen, die wiederum einen synchronen Aufruf zu Ihrem Repository macht. Dies ermöglicht das Repository weiterhin in einer synchronen Weise arbeiten, während die Fassade der asynchronen Aspekte Ihres Anrufs verwaltet.