2010
18.01
18.01
Voici la dernière partie de l’article sur la communication entre Flex et un backend .Net
Voir la première partie : Flex & .Net (part 1/3) : FluorineFX
Voir la seconde partie : Flex & .Net (part 2/3) : WebORB
L’utilisation de ces deux solutions nous a permis très facilement d’appeler des méthodes de classe écrites en C# à partir de Flex. J’ai constaté certaines similitudes et certaines différences marquées entre WebORB, la solution commerciale et FluorineFx, l’alternative open source.
Elles disposent toutes deux d’une fonctionnalité de console qui permet de visualiser toutes les classes exposées au client d’accès distant et de les invoquer. Elles sont aussi parfaitement intégrées à Visual Studio.
WebOrb .net
On apprécie :- La simplicité d’installation
- La richesse de l’application console qui gère également la sécurité à différents niveaux (namespace/classe/méthode)
- L’outil de génération de code (AS – C# et VB.net) intégré à l’application console.
- La génération d’un projet C# ou Vb.Net à l’aide de la structure de la base de données.
- Le fait que l’ensemble de l’Assembly soit exposée à l’utilisateur. Cependant, il est possible de gérer la visibilité des méthodes à l’aide d’un fichier .config.
- Le recours à une licence commerciale (sauf en cas de redistribution).
FluorineFX
On apprécie :- La simplicité d’installation
- La licence open source.
- La génération de code (AS) intégré à l’application Console.
- L’annotation permettant d’exposer des classes comme des services (annotation RemotingService)
- Le manque d’exemples dans la documentation.
- L’implémentation spécifique pour les tableaux, les DataSets et DataTables (moins intuitive que celle de WebORB).
- La pauvreté de l’application console (beaucoup moins riche que WebORB).
- La gestion manuelle (via des fichiers de configuration) de la sécurité d’accès aux classes de services.
2 commentaires
Ajouter votre commentaire