Flex 4.5 удаленные объекты - PullRequest
Новая
       30

Flex 4.5 удаленные объекты

0 голосов
/ 18 октября 2011

Я очень плохо знаком с удаленным доступом в flex. Я использую flex 4.5 и общаюсь с веб-приложением, созданным кем-то другим в команде, использующим AMF. Они использовали Zend_AMF для сериализации и десериализации данных.

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

Из примеров удаленного взаимодействия, которые я видел в Интернете и в Adobe, кажется, что мне нужно определить объект удаленного взаимодействия для КАЖДОГО сервиса: 

<mx:RemoteObject id="testservice" fault="testservice_faultHandler(event)" showBusyCursor="true" destination="account"/>

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

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

Итак, вопрос в том, есть ли способ решить эту проблему без необходимости определять нагрузки или удаленные объекты и без необходимости погружаться слишком глубоко и начинать самостоятельно обрабатывать события удаленного удаленного взаимодействия?

Приветствия

1 Ответ

1 голос
/ 18 октября 2011

Кажется необычным для приложения требовать так много удаленных объектов. Я работал над чрезвычайно большими приложениями, и мы обычно получаем не более ~ 6-10 объявлений RemoteObject.

Несмотря на то, что вы не приводите в своем посте много подробностей о вариантах удаленных объектов, я подозреваю, что вы можете путать RemoteObject с Operation.

Обычно вы объявляете экземпляр RemoteObject для каждой конечной точки в вашем приложении. Тем не менее, эта конечная точка может (и обычно делает) предоставлять много различных методов для вызова. Каждый из этих методов на стороне сервера получает результаты на стороне клиента Operation.

Вы можете явно объявить их, если хотите, однако RemoteObject создает для вас Operation s, если вы их не объявляете: 

 var remoteObject:RemoteObject;
 // creates an operation for the saveAccount RPC call, and invokes it, 
 // returning the AsyncToken
 var token:AsyncToken = remoteObject.saveAccount(account); 
 token.addResponder(this); 
  //... etc

Если вы взаимодействуете с одним слоем сервера, вы часто можете обойтись с одним RemoteObject, указывающим на одно место назначения в API, которое предоставляет множество методов. Этот подход часто называют фасадом API и может быть очень полезен, если подкреплен строгой дисциплиной внедрения зависимостей в API.

Другим распространенным подходом является разделение методов API по логическим бизнес-областям, например, AccountService, ShoppingCartService и т. Д. Преимущество заключается в возможности смешивать и сопоставлять протоколы между службами (например, AccountService может работать через HTTPS) .

Как вы решите разделить эти удаленные объекты, зависит от вас. Тем не менее, 60 в одном приложении звучит немного подозрительно для меня.

...