Dépôts DDD et asynchrones

Question

Nous travaillons sur un client riche (écrit en Flex) connecté à un serveur Java, à l'aide de RMI et de JMS. Je pensais à l’implémentation DDD du client afin qu’il dispose de référentiels pour les opérations CRUD sur les objets du domaine.

Cependant, le problème est que toutes les communications dorsales sont asynchrones et que je ne peux pas forcer le client à attendre avant de continuer jusqu'à ce qu'il ait reçu une réponse. Cela signifie que, à un niveau bas, je peux appeler une méthode sur un objet distant et obtenir un AsyncToken comme valeur de retour. Je peux ensuite écouter les événements sur l'asynctoken pour voir si l'appel a réussi ou échoué. Cela rompt toutefois l'idée principale derrière un référentiel, cacher les détails techniques au client.

Il pourrait y avoir 2 options, je suppose:

1. les méthodes du référentiel renvoient-elles l'asynctoken, ce qui me semble une solution compliquée
2. demander aux méthodes de renvoyer une collection vide (pour un findAll par exemple) à remplir lors de la réception de la réponse.

Les deux ont des avantages et des inconvénients et je souhaiterais obtenir votre avis.

(pour aller plus loin, quelles seraient les bonnes stratégies de mise en cache? Selon la situation, je ne souhaite pas que le référentiel appelle le serveur à chaque fois que je lui demande toutes les entités. En quoi cela affecterait-il la signature des méthodes? le référentiel.)

Answer 1

Flex et Flash Remoting sont intrinsèquement asynchrones. Par conséquent, lutter contre ce paradigme vous causera beaucoup de problèmes. Nos délégués de service renvoient AsyncToken de chaque méthode et cela ne nous a jamais posé de problème.

Si vous voulez vous assurer que l'application ne restitue pas une nouvelle vue ou n'effectue aucune autre logique jusqu'à ce que le résultat / défaut revienne, vous pouvez procéder comme suit:

1. Attachez un écouteur d'événement pour un événement personnalisé qui appellera votre "code de résultat / d'erreur"
2. Effectuer l'appel asynchrone
3. Traiter le résultat / le défaut
4. Distribuez l'événement personnalisé pour déclencher votre écouteur à partir de # 1

N'oubliez pas que cela entraînera beaucoup de code de chaudière agaçant chaque fois que vous effectuez un appel asynchrone. J'examinerais très attentivement si vous avez vraiment besoin d'un chemin d'exécution synchrone.

Answer 2

Je recommanderais de renvoyer un AsyncToken, car renvoyer une collection vide semble tout simplement inacceptable.

Si vous renvoyez des données à partir d'une mémoire cache, renvoyez un CompletedAsyncToken (: AsyncToken) qui déclenche automatiquement l'événement COMPLETE avec les données chaque fois que l'événement COMPLETE est abonné (puis supprimé du gestionnaire).

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

Une stratégie serait de créer une façade devant le référentiel. Votre client effectuera des appels asynchrones sur la façade, qui à son tour effectuera un appel synchrone à votre référentiel. Cela permettra à votre référentiel de continuer à fonctionner de manière synchrone pendant que la façade gère les aspects asynchrones de votre appel.