¿El mejor método para la comunicación de Flex a PHP?
https://stackoverflow.com/questions/652134
-
19-08-2019 - |
italiano
english
français
española
中国
日本の
العربية
Deutsch
한국어
Português
RussianPregunta
¿Cuál es el mejor método para la comunicación entre Flex y PHP?
En el pasado, utilizamos AMFPHP con AS2, y funcionó muy bien en su mayor parte (la ventaja de AMFPHP es que también tiene un modo JSON que puede permitirle usar sin problemas el mismo PHP remoto con frontales JavaScript o Actionscript) .
Sin embargo, parece que AMFPHP ya no se mantiene realmente. Entonces, ¿qué recomiendan las personas para reemplazarlo? Hasta ahora, lo que he encontrado es:
- Zend_AMF ( parece demasiado complejo para nosotros, de lo contrario no estamos usando el marco Zend)
- AMFPHP (hubo algunas actualizaciones realizadas para admitir Flex, y parece bastante estable, pero no estoy seguro sobre el soporte a largo plazo)
- XML (AS3 tiene buenas rutinas de manejo de XML, pero es más difícil en el lado de PHP)
- WebORB (No tengo experiencia con esto)
- Roll-our-own utilizando JSON o algún otro sistema de serialización de datos a texto (php's serialize (), XML, etc., etc.)
Principalmente me estoy inclinando hacia AMFPHP, incluso debido a las desventajas, ya que eso es a lo que estoy acostumbrado. ¿Alguna razón por la que debería considerar cambiar a otra cosa?
Solución
Si desea tener una comunicación rápida y eficiente, le recomiendo que siga con un protocolo AMF en lugar de un formato personalizado REST o JSON.
ZendAMF en realidad no es muy confuso. Vea el tutorial de introducción en GotoAndLearn , es bastante simple.
Y para que lo sepas, algunos de los desarrolladores de AMFPHP se mudó a trabajar en ZendAMF. Entonces, en cierto sentido, ZendAMF es la continuación de AMFPHP.
Otros consejos
ZendAMF Buena lectura corta: http://theflashblog.com/?p=441
Para mí esto no es obvio. El marco Zend es uno de los mejores marcos PHP existentes, y ahora puedes hablar con clientes Flash. Completa con el soporte de Adobe, eso es un trato hecho en mi libro.
Alternativas:
WebORB para php http://www.themidnightcoders.com/products/weborb-for-php
AMFPHP http://www.amfphp.com Si lees la URL anterior, probablemente sabrás por qué esto ya no está en mi radar.
No puedo decirte qué es lo mejor (porque de todos modos eso es probablemente algo subjetivo), pero lo que puedo hacer es contarte sobre un proyecto mío reciente.
Como se trataba de una aplicación web muy rica y las solicitudes de datos al servidor serían frecuentes, quería asegurarme de que el tamaño de las solicitudes fuera lo más pequeño posible. Esto significa elegir JSON como formato.
Luego, debido a la naturaleza de la aplicación y al hecho de que mis desarrolladores de flash / flex estaban a 1000 millas de distancia, necesitaba una API que fuera simple y sin estado. Esto finalmente nos llevó a HTTP + REST.
Entonces, la capa de comunicación de mi aplicación es un conjunto simple de recursos REST basados ??en Zend Framework con URI como
user/10
review/15
location/8/reviews
Todos devuelven JSON. También hay un formato JSON común para todos los errores (las excepciones quedan atrapadas y convertidas en objetos JSON) para que el cliente flash pueda manejar fácilmente las fallas.
Si no está utilizando un marco como Zend, el AMFPHP normal sigue siendo excelente, aunque no sea por otra razón que sea simple. Creo que si te sientes cómodo con él, ¿por qué no lo haces? La cuestión sobre el papel de estas interfaces AMF es que realmente no necesitan hacer demasiado, y lo que AMFPHP tiene en el mapeo de clases, el análisis de conjuntos de registros en ArrayCollection, gran rendimiento ... incluso funciona bien con XML, ya que se comprime El navegador de servicios combinado con Charles también me ha cubierto.
No he podido tener mucho sentido de cómo el esfuerzo de ZendAMF se relaciona con el AMFPHP original. Si bien puedo cavar, solo digo que al seguir la lista de correo AMFPHP en Nabble, leer el blog de Wade Arnold ... simplemente no está del todo claro.
Debería considerar usar Zend AMF. Zend Framework está diseñado para ser un marco de selección y elección, por lo que está completamente bien elegir un solo componente (en este caso, Zend AMF) para su aplicación.
Zend AMF es extremadamente fácil de usar. Todo lo que tiene que hacer es especificar las funciones / clases que desea exponer y especificar la asignación de clases a sus clases de script de acción. Todo lo demás es bastante transparente.
Este enlace es un screencast que muestra cómo usar WebORB para PHP WDMF (WebORB Data Management for Flex).
En todos los proyectos que involucran backend de Flash y PHP, trabajé con solicitudes AMFPHP o XML.
AMFPHP realmente simplifica entender la aplicación para el mantenimiento futuro, aunque vincula todo a esa tecnología específica e implica una sobrecarga adicional en el lado del servidor, para crear todas las clases necesarias.
Según XML, bueno, lo que obtienes aquí son servicios web REST estándar y no depende de Flash (también puedes extraer datos de una aplicación de escritorio, por ejemplo, mientras usas JSON o cualquier otra tecnología que dependa de los navegadores) no permita eso).
Si desea un 100% de "soporte" futuro, entonces recomendaría lo que no necesita ningún soporte: XML.
XML en PHP puede ser mucho más simple con SimpleXML .
Simplemente usaría JSON como sus retornos para llamadas simples contra su API PHP.
Definitivamente iría por WebORB. Lo usé con .NET en un trabajo anterior que tuve y fue un placer codificarlo. Su facilidad de uso y su consola de administración bien pensada lo hacen muy rápido de aprender, y su documentación es muy completa; Sé que es tentador quedarse con AMF solo porque es lo que ya sabes, pero creo que vale la pena probar WebORB.
Eche un vistazo a este screencast para la generación de Actionscript con PHP, es bastante elegante.
Saludos.
PHP tiene una función bastante buena de serialize () , así que para un proyecto reciente que hice (puntajes altos para un juego), utilicé Sephiroth's Serializador . Hace que la serialización en el lado de Flash sea casi tan fácil como en PHP. El serializador también se ocupa de los tipos de datos (a diferencia de json / xml) como AMF.
Desventaja: no es tan compacto como AMF, pero eso no es nada que la compresión gzip no pueda manejar.
AMF tiene una ventaja situacional bonita. Si está buscando transferir objetos grandes y complejos, vaya con AMF. Pero poco sabe la gente sobre los gastos generales que lleva AMF cuando transfiere objetos pequeños. Si solo está transfiriendo un objeto con 3 propiedades, el uso de AMF puede triplicar el tamaño de su carga útil.
En una nota al margen, soy un gran defensor de la arquitectura RESTful. Dado que JSON y AMF son solo representaciones, puede crear un servicio REST que acepte ambos y negociar la representación real con su cliente en tiempo de ejecución.
" Si desea tener una comunicación rápida y eficiente, le recomiendo que se adhiera a un protocolo AMF "
Y si quieres una comunicación rápida, eficiente y generalizada, ve con json. Luego, su servicio web estará disponible para flashear, ajax o solicitudes http regulares.
