创建 AMF 包装器
我正在创建一个移动应用程序，它将连接到 zendamf 实现，以检索某些信息来存储并向用户显示。
网关上有多个 php 类来处理用户、订单、产品等内容。
因此，我有一个名为 Remotehandler 的包，其下有类，remotehandler.orders、remotehandler.product、remotehandler.users。这意味着对于每个类，我可以执行以下操作：
而不是为每种类型的调用创建一个连接，我想进行很多次。
我想为每个调用系列创建一个包装类 IE Users
- createUser - 经过一番搜索后，调用 php 函数来创建用户
- DeleteUser
- UpdateUser
我遇到了这篇文章 http://flexdevtips.blogspot.com/2009 /05/using-flex-and-amfphp-without-services.html 它展示了如何在代码中处理网络连接。但如果您打算拨打一个电话，则会写明。
有谁有关于如何将其转换为一个类的任何想法或示例，该类将允许我指定不同的源（php 类函数）。
谢谢贾克诺
I am creating a mobile app that will connect to a zendamf implementation to retrive certain information to store and display to the user.
There are multiple php classes on the gateway to handle things like users, Orders, Products etc.
Therefore I would have a package called remotehandler with classes under it, remotehandler.orders remotehandler.product, remotehandler.users. Which would mean for each class I could do the following:
instead of creating a connection for each type of call I want to make lots of times I was thinking that it might be better to create a wrapper class for each call family I.E
Users
- createUser - calls a php function to create the user
- DeleteUser
- UpdateUser
after some searching I came accross this post
http://flexdevtips.blogspot.com/2009/05/using-flex-and-amfphp-without-services.html
which shows how to deal with netconnection in code. but it is written if you are planning on making a single call.
Does anyone have any ideas or example on how I could turn this in to a class that would allow me to specific different source(php class functions).
Thanks
JaChNo
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
只需将类上的一个属性（我们称之为源）公开为 getter/setter 对，设置后会更改 RemoteObject 的源。
但是，我发现最好为我期望的每种返回类型使用不同的服务类，因为这样我就可以模拟该服务，并在处理不需要实时连接数据库的事情时直接放入模拟中（例如剥皮）。
Simply expose a property on your Class (let's call it source) as a getter/setter pair that, when set, changes the source of the RemoteObject.
However, I find it is better to have a different Service Class for each return type I expect, because I can then mock the service and just drop in the mock when I am working on things that don't require a live connection to the database (such as skinning).