Лучший способ реализовать асинхронные обратные вызовы / события 1: 1 в ActionScript 3 / Flex / AIR?

Question

Я использовал шаблон команды в моих проектах Flex с асинхронными маршрутами обратного вызова, требуемыми между:

• тот, кто создал экземпляр данного командного объекта и командный объект,
• объект command и объект "доступ к данным" (т.е.кто-то, кто обрабатывает удаленные вызовы процедур по сети к серверам), которые вызывает объект command.

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

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

Вот пример, иллюстрирующий мой текущий метод:

• У меня может быть объект просмотра, который порождает DeleteObjectCommand экземпляр из-за какого-то действия пользователя, передающий ссылки на две свои собственные закрытые функции-члены (одна для успеха, одна для неудачи:допустим, "deleteObjectSuccessHandler()" и "deleteObjectFailureHandler()" в этом примере) в качестве функции обратного вызова ссылается на конструктор командного класса.
• Затем объект command повторил бы этот шаблон со своим подключением к объекту "доступ к данным".
• Когда RPC по сети успешно завершен (или произошел сбой), вызываются соответствующие функции обратного вызова, сначала объектом "доступ к данным", а затем объектом command, так что, наконец, объект view, который в первую очередь создал экземпляр операции, получает уведомление о том, что его deleteObjectSuccessHandler() или deleteObjectFailureHandler() звонил.

Answer 1

Я попробую еще одну идею:

Пусть ваш объект доступа к данным возвращает свои собственные AsyncTokens (или некоторые другие объекты, которые инкапсулируют ожидающий вызов) вместо AsyncToken, который поступает из вызова RPC.Итак, в DAO это выглядело бы примерно так (это очень схематичный код).:

public function deleteThing( id : String ) : DeferredResponse {
    var deferredResponse : DeferredResponse = new DeferredResponse();

    var asyncToken : AsyncToken = theRemoteObject.deleteThing(id);

    var result : Function = function( o : Object ) : void {
        deferredResponse.notifyResultListeners(o);
    }

    var fault : Function = function( o : Object ) : void {
        deferredResponse.notifyFaultListeners(o);
    }

    asyncToken.addResponder(new ClosureResponder(result, fault));

    return localAsyncToken;
}

Тот Самый DeferredResponse и ClosureResponder классов, конечно, не существует.Вместо того чтобы изобретать свой собственный, вы могли бы использовать AsyncToken вместо того, чтобы DeferredResponse, но публичная версия AsyncToken похоже, у него нет никакого способа запустить ответчики, так что вам, вероятно, все равно придется его подклассировать. ClosureResponder это всего лишь реализация IResponder это может вызвать функцию при успешном выполнении или неудаче.

В любом случае, способ, которым приведенный выше код выполняет свою работу, заключается в том, что он вызывает службу RPC, создает объект, инкапсулирующий ожидающий вызов, возвращает этот объект, а затем, когда RPC возвращается, одно из замыканий result или fault вызывается, и поскольку у них все еще есть ссылки на область видимости, как это было при выполнении вызова RPC, они могут запускать методы в ожидающем вызове / отложенном ответе.

В команде это выглядело бы примерно так:

public function execute( ) : void {
    var deferredResponse : DeferredResponse = dao.deleteThing("3");

    deferredResponse.addEventListener(ResultEvent.RESULT, onResult);
    deferredResponse.addEventListener(FaultEvent.FAULT,   onFault);
}

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

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

Answer 2

Многие классы Flex RPC, такие как RemoteObject, HTTPService, и т.д.Возврат AsyncTokenэто когда ты им звонишь.Похоже, это именно то, что вам нужно.В основном AsyncToken инкапсулирует ожидающий вызов, позволяя регистрировать обратные вызовы (в виде IResponder экземпляры) для конкретного вызова.

В случае HTTPService, когда ты позвонишь send() ан AsyncToken возвращается, и вы можете использовать этот объект для отслеживания конкретного вызова, в отличие от ResultEvent.RESULT, который срабатывает независимо от того, какой это вызов (и вызовы могут легко поступать в другом порядке, чем они были отправлены).

Answer 3

AbstractCollection - лучший способ работать с постоянными объектами в Flex / AIR.GenericDAO дает ответ.

DAO - это объект, который управляет выполнением операции CRUD и других распространенных Операций, выполняемых над ValueObject (известным как Pojo в Java ).GenericDAO - это многоразовый класс DAO, который может использоваться в общем виде.Цель:

В JAVA IBM GenericDAO для добавления нового DAO необходимо выполнить простые действия Добавить valueobject (pojo).Добавьте файл сопоставления hbm.xml для valueobject.Добавьте 10-строчный файл конфигурации Spring для DAO.

Аналогично, в проекте AS3 Swiz DAO.Мы хотим достичь аналогичного уровня достижений.

Модель GenericDAO на стороне клиента:Поскольку мы работали над языком на стороне клиента, мы также должны были управлять постоянной коллекцией объектов (для каждого ValueObject).Использование:Источник:http://github.com/nsdevaraj/SwizDAO