DDD и асинхронные репозитории

Question

Мы работаем над богатым клиентом (написанным на Flex), который подключен к серверу Java, используя как RMI, так и JMS. Я думал о внедрении клиента в режиме DDD, так что у него есть репозитории для операций CRUD для объектов домена.

Проблема в том, что вся бэкэнд-связь происходит асинхронно, и мне не удастся заставить клиента ждать, пока он не получит ответ. Это означает, что на низком уровне я могу вызвать метод на удаленном объекте, и я получаю AsyncToken как возвращаемое значение. Затем я могу прослушивать события на асинккокене, чтобы узнать, прошел или не прошел вызов. Это, однако, нарушает основную идею хранилища, скрывает технические детали от клиента.

Там может быть 2 варианта я думаю:

1. имеют методы в хранилище вернуть AsyncToken, который, кажется, как грязный раствор для меня
2. имеют методы возвращают пустую коллекцию (для FindAll например), которые будут заполняться при получении ответа.

У обоих есть плюсы и минусы, и я хотел бы получить от вас ответы.

(что еще лучше, какие бы стратегии были кеширования? Зависит от ситуации, я не хочу, чтобы репозиторий вызывал сервер каждый раз, когда я запрашиваю от него все сущности. Как это повлияет на подпись методов на репозитории.)

Answer 1

Flex и флэш-Remoting неотъемлемо Асинхронный так борется против этой парадигмы собирается дать вам массу неприятностей. Наши делегаты службы возвращают AsyncToken из каждого метода, и у нас никогда не было проблем с ним.

Если вы хотите, чтобы убедиться, что приложение не делает новый вид или не выполнять некоторые другие логики, пока результат/ошибка возвращается, вы можете сделать следующее:

1. Приложите слушателя событий для пользовательское событие, который будет вызывать ваш «пост результата/код ошибки»
2. Сделать асинхронный вызов
3. Handle результата/неисправности
4. Отправку пользовательских события, чтобы вызвать прослушиватель # 1

Помните, что это приведет к большому количеству раздражающего кода кипения при каждом асинхронном вызове. Я бы очень тщательно подумал, действительно ли вам нужен синхронный путь выполнения.

Answer 2

Одним из них было бы создание фасада перед репозиторием. Ваш клиент сделает асинхронные вызовы на фасад, что в свою очередь делает синхронный вызов вашему репозиторию. Это позволит вашему репозиторию продолжать работать синхронно, в то время как фасад управляет асинхронными аспектами вашего вызова.

Answer 3

Я бы порекомендовал вернуть AsyncToken, поскольку возврат пустой коллекции просто чувствует себя не так.

В случае, когда вы возвращаете данные из кеша, верните CompletedAsyncToken (: AsyncToken), который автоматически запускает событие COMPLETE с данными всякий раз, когда на событие COMPLETE подписывается (а затем удаляется обработчик).

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