Flex 4.5 远程处理对象
我对 Flex 中的远程处理非常陌生。我正在使用 flex 4.5 并与团队中其他人使用 AMF 构建的 Web 应用程序进行对话。他们使用 Zend_AMF 来序列化和反序列化数据。
我目前面临的主要问题之一是我需要与很多服务(大约 60 个左右)交谈。
从我在网上和 adobe 上看到的远程处理示例来看,我似乎需要为每个服务定义一个远程处理对象:
<mx:RemoteObject id="testservice" fault="testservice_faultHandler(event)" showBusyCursor="true" destination="account"/>
有了这么多服务,我想我可能需要定义其中大约 60 个,我认为这不是非常优雅。
与此同时,我一直在使用 Pinta 来测试 AMF 端点。 Pinta 似乎能够允许人们定义任意数量的服务、方法和参数,而没有任何这些限制。深入研究源代码,我发现他们实际上已经深入研究了远程处理,并且正在处理许多低级别的东西。
所以,问题是,有没有一种方法可以解决这个问题,而不必定义负载或远程对象,也不必深入到我们自己处理低级远程事件?
干杯
I am very new to remoting in flex. I am using flex 4.5 and talking to a web application built by someone else on the team using AMF. They have used Zend_AMF to serialize and unserialize the data.
One of the main issues I am facing at the moment is that I will need to talk to a lot of services (about 60 or so).
From examples on remoting I have seen online and from adobe, it seems that I need to define a remoting object for EACH service:
<mx:RemoteObject id="testservice" fault="testservice_faultHandler(event)" showBusyCursor="true" destination="account"/>
With so many services, I think I might have to define about 60 of those, which I don't think is very elegant.
At the same time, I have been playing with Pinta to test out the AMF endpoint. Pinta seems to be able to allow one to define an arbitary amount of services, methods and parameters without any of these limitations. Digging through the source, I find that they have actually drilled down deep into the remoting and are handling a lot of low level stuff.
So, the question is, is there a way to approach this problem without having to define loads or remoteobjects and without having to go down too deep and start having to handling low level remoting events ourselves?
Cheers
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

应用程序需要这么多 RemoteObjects 似乎很不寻常。我曾经开发过非常大的应用程序,我们通常最终得到的 RemoteObject 声明不会超过 6-10 个。
尽管您在帖子中没有提供有关 RemoteObjects 变体的大量细节,但我怀疑您可能会将
RemoteObject
与Operation
混淆。您通常会为应用程序中的每个端点声明一个 RemoteObject 实例。但是,该端点可以(并且通常确实)公开许多要调用的不同方法。这些服务器端方法中的每一个都在客户端
操作
中获取结果。如果您愿意,您可以显式声明这些,但是如果您不声明它们,RemoteObject 会为您构建
Operation
:如果您正在与单个服务器层交互,则通常可以逃避单个 RemoteObject,指向 API 上的单个目标,它公开了许多方法。这种方法通常被称为 API Façade,如果以 API 上可靠的依赖注入规则为后盾,它会非常有用。
另一种常见的方法是按逻辑业务领域(例如 AccountService、ShoppingCartService 等)分离 API 方法。这样做的好处是能够混合使用 API 方法。匹配服务之间的协议(例如,AccountService 可以通过 HTTPS 运行)。
如何选择拆分这些 RemoteObject 由您决定。然而,单个应用程序中的 60 个对我来说听起来有点可疑。
It seems unusual for an application to require that many RemoteObjects. I've worked on extremely large applications, and we typically end up with no more than ~6-10 RemoteObject declarations.
Although you don't give a lot of specifics in your post about the variations of RemoteObjects, I suspect you may be confusing
RemoteObject
withOperation
.You typically declare a RemoteObject instance for every end-point in your application. However, that endpoint can (and normally does) expose many different methods to be invoked. Each of these server-side methods gets results in a client-side
Operation
.You can explicitly declare these if you wish, however the RemoteObject builds
Operation
s for you if you don't declare them:If you're interacting with a single server layer, you can often get away with a single RemoteObject, pointing to a single destination on the API, which exposes many methods. This is approach is often referred to as an API Façade, and can be very useful, if backed with a solid dependency injection discipline on the API.
Another common approach is to segregate your API methods by logical business area, eg., AccountService, ShoppingCartService, etc. This has the benefit of being able to mix & match protocols between services (eg., AccountService may run over HTTPS).
How you choose to split up these RemoteObjects is up to you. However, 60 in a single applications sounds a bit suspect to me.