Apache Adobe Flex TutorialTutoriaux Adobe Flex & AIR en Français

Comprendre les différentes stratégies de Data Communication

Quand on développe une application Flex qui utilise des donnés distantes, il est important de comprendre les différentes stratégies disponibles pour gérer cette communication, et comment choisir la bonne pour une application. Si vous débutez avec la plateforme d'application Flash, il est important d'apprendre comment la communication de données fonctionne dans Flash Player et comment la comparer avec d'autres que vous connaissez peut-être déjà en ayant développé sur d'autres plate-formes. Par exemple, ce que vous connaissez en ayant travaillé avec des applications HTML ou Ajax peut être utile, mais vous ne devez jamais assumer que les applications Flex ont le même comportement que les applications construites sur d'autres plateformes.

Comme vous le savez déjà, les applications Flex sont lues par Flash Player 9. A l'exception des application Flex créées en utilisant les Flex Data Services, presque toutes les applications Flex sont composés de fichiers SWF précompilés qui sont chargés dans Flash Player sur le client. Ces fichiers SWF sont initialement requetés depuis le serveur mais ils sont lus par le client. Cela veut dire que la donnée dynamique (toute donnée non compilés statiquement dans le SWF) doit être requêtée à l'exécution depuis le client vers un serveur.

Parce que les applications Flex sont Stateful, elles n'ont pas besoin de requête d'une nouvelle page et d'un rafraichissement de l'écran pour faire des requêtes et gérer la réponse. Ce comportement est commun entre les applications Flex et Ajax qui ne sont pas gérés par pages, les applications Flex sont gérés par événements. Même si la vue à l'intérieur d'une application Flex peut ne pas changer, elle peut faire des requêtes et recevoir des réponses. C'est la raison pour laquelle la communication de données avec Flex requiert des stratégies différentes par rapport à celles employées pour les applications gérées par page.

Le Framework Flex propose des composants pour créer cette communication de data en utilisant aussi bien les requêtes HTTP standard que les requêtes SOAP. Ces composants sont bénéfiques quand on utilise la première des grandes stratégies de data communication: placer le code (le composant) qui fait la requête à l'intérieur de la classe ou du document MXML qui utilise la donnée. Cette stratégie décentralise la communication avec les données, ce qui cause plusieurs problèmes:

• Gérer la data communication est difficile quand le code est décentralisée, simplement car cela rend difficile le fait de trouver le code parfois
• Quand la donnée est couplée avec une vue particulière qui utilise la donnée, cette donnée n'est pas accessible aux autres parties de l'application. Cela peut sembler ne pas être un problème sauf s'il on considère que de nombreuses applications utilisent la même donnée à des endroits différents, et si vous placez le code pour la communication à l'intérieur de la vue qui utilise la data, vous rendez difficile la synchronisation des données et vous pourriez avoir à faire plusieurs requêtes pour la même donnée
• Décentraliser le code qui sert la communication de data rend l'application fragile car s'il on change n'importe quel point à propos du process de communication (protocole, API, etc…), on peut casser l'application à plusieurs endroits. A l'inverse, quand la communication est centralisée, il est relativement facile d'adapter l'application quand on besoin de faire du changement.

Bien que cette première stratégies comporte ces nombreux pièges, elle n'est pas sans avantages. Ces composants fournissent une manière plus rapide de créer des applications communicantes. Ils sont utiles pour les prototypes, les applications de test, ou les plus petites applications qui ont moins d'exigence technique.

La seconde stratégie centralise la communication des données en utilisant des objets "remote proxy" (proxy distants). Les "remote proxy" fournissent un emplacement centralisé pour le code de la data communication et ils cachent les détails sur comment la communication est mise en place au reste de l'application. Même si l'implémentation change, le reste de l'application peut continuer à faire des appels sur les objets remote proxy.