Fondamentaux d'architecture d'une application Flex

Slide 1: Fondamentaux d'architecture d'une application Flex Adobe eSeminar - 06/06/08 David Deraedt Centre Regart.net

Slide 2: Introduction Comment organiser le code d'une application Flex ? Ne sont pas concernés : • Démonstrations • Exemples • Très petites applications Généralement : • Enjeu commercial • Utilisateurs "réels" • Durée de vie importante • Travail en équipe (?)

Slide 3: Contraintes Constat : Maintenance > Développement initial Méthodes agiles = cycles courts, itératifs Faciliter : • Modifications • Tests / Débogage • Travail en équipe • Productivité

Slide 4: Bonnes pratiques Séparer les responsabilités • Dans le code • Dans l'équipe Limiter le couplage • Indépendance • Modularité Partager • Informations (Méthodologie et terminologie, documents) • Outils (factorisation, mutualisation)

Slide 5: Mise en oeuvre POO Contexte technologique • Encapsulation • Flex = RIA = Couche • Polymorphisme présentation d'une • Design patterns architecture 3 tiers • Architecture patterns

Slide 6: Rich Internet Application Architecture 3 tiers Rich Internet Application Architecture RIA: • Client s'exécute sur poste client • Client conscient de son état, "stateful" • Le client connaît les détails d'implémentation du serveur • Architecture plus "client / serveur"

Slide 7: Rich Internet Application Répartition des rôles Client / Serveur • Serveur d'application = règles métiers • Client riche = relation à l'utilisateur Quelle architecture côté serveur ? • Présentation : Client Riche • Intégration : Business Objects via des Services • Persistance (ORM) : VOs / DTOs, DAO, ActiveRecord, ...

Slide 8: Rich Internet Application

Slide 9: Rich Internet Application Le client (RIA Flex) communique avec : • L'API du service (parfois, directement DAOs) • Les VOs / DTOs Mais de quelle manière ?

Slide 10: Communication Avec Flex, deux familles d'outils : • Communication temps réel • Communication RPC asynchrone RPC : • HTTPService • WebService • RemoteObject

Slide 11: HTTPService • Requêtes HTTP(s) • URLencoding, (couple identifiant/valeur voire XML) • Script / Page ASP, JSP, PHP, ... • Services REST Les données échangées ne sont pas typées. => Intérêt limité à de "petites" tâches individuelles - Upload de fichiers, création de fichiers, Proxies, etc... ou => JSON (typage des données)

Slide 12: WebService Au sens SOAP • Envoie / reçoit SOAP (XML) • Web Service Definition Language (WSDL) • Echanges de quelques données "typées" : • Types primitifs AS3 (Boolean, int, uint, Number, String, ...) • Quelques types complexes du top level (Array, Date) • Sérialisation/ Désérialisation côté Flex • Pas de type personnalisé

Slide 13: RemoteObject • Remoting : AMF : ActionScript Message Format = AS binaire • HTTP(S) ou protocoles temps réél • AMF3 = AS3 (Flex), AMF0 = AS1 + AS2 • Spécifications ouvertes Avantages • Performance (car binaire), cf Census • Confort de développement car... Données typées • Types primitifs • Types complexes Top Level (selon passerelle) • Types personnalisés : Value Objects ([RemoteClass]) ... = 100 % POO !

Slide 14: RemoteObject Inconvéniant : Nécessite une passerelle AMF3 côté serveur (Sérialisation / Désérialisation AMF3) Solutions gratuites et OpenSource pour toutes technos • J2EE : BlazeDS, WebORB, GraniteDS, LCDS(ES) • .NET : Fluorine, WebORB • PHP : AMFPHP, WebORB, SABREAMF • ROR : RubyAMF, WebORB • Python : PyAMF • Perl : ?

Slide 16: Architecture côté Flex A priori : hiérarchie de composants MXML. Sommet de la pyramide = Document principal (Application, WindowedApplication, Module) Les composants : • Représentent les données graphiquement • Reçoivent l'interaction utilisateur => C'est la vue d'un MVC • Ces vues peuvent elles être indépendantes ? • Qui va s'occuper du reste (logique de l'application) ?

Slide 17: Indépendance des composants Permise par 2 Mécanismes fondamentaux : • DataBinding = Mise à jour des données automatisée (Model -> View) • Evénements = Transmission l'interaction utilisateur (View -> Controller) Note : attribut source de la balise Script "Code Behind" purement formel => Insuffisant

Slide 18: Limites du framework Flex Cas classique : le document principal gère toute la logique de l'application ! Conséquence : • Vues bien découplées • Reste de l'application très monolithique (code spaghetti) Conclusion: • Reste la solution la plus simple pour de "petites" applications • Très vite limité

Slide 19: Un MVC côté Flex

Slide 20: Un MVC côté Flex : Le modèle • Stocke les données • Ne sait pas comment elles sont représentées • C'est l'état de notre application • Aucune logique (sauf accès aux données) • Souvent, simple liste de propriétés publiques • VOs, ArrayCollections • Tout est "Bindable"

Slide 21: Un MVC côté Flex : Le modèle

Slide 22: Un MVC côté Flex : Le contrôleur • Cerveau de l'application • Logique entre vue et modèle • Ecoute les événements diffusés par les vues • Met à jour le modèle • Ne connaît rien des vues Design pattern "Command" • Déléguer les tâches à des objets (Commands) • Command = logique derrière une User Gesture • Permet de traiter chaque tâche comme un objet (historique, undo, ...)

Slide 23: Un MVC côté Flex : Le contrôleur

Slide 24: Un MVC côté Flex : Le contrôleur Problème de fond : Comment faire remonter les événements vers un Contrôleur ? • Bubbling : s'appuie sur la display list (pas suffisant) • Remonter parent par parent : clone(), dispatchEvent(event) => Difficile de faire quelque chose de propre ET standard

Slide 25: Un MVC côté Flex : Le contrôleur Parfois, besoin de mettre à jour une vue dans une commande • Problème : Le contrôleur ne doit rien savoir de la vue • Solution : Diffuser un événement écouté par un tiers qui, lui connaît la vue. (View Helpers, View Controlers ...)

Slide 26: Un MVC côté Flex : Le contrôleur

Slide 27: La couche métier • Les commandes doivent communiquer avec le Service • Risque de couplage entre les deux • Déléguer à un objet la communication avec le Service Le "BusinessDelegate" : • Expose l'API du Service en AS3 • Encapsule l'implémentation de sa communication • Transmet le résultat à un Responder (Command) Avantages • Découplage entre Command et Service • Typage, Intelliscence

Slide 28: La couche métier

Slide 29: Vue d'ensemble

Slide 30: Remarques Peut paraître abstrait et compliqué, mais • Beaucoup de classes sont très simples • Toutes les classes sont courtes et lisibles • Pas nécessaire de tout utiliser • Concerne la majorité des applications • Méthodologie et terminologie commune • Adapté aux méthodes agiles / itératives De plus, des outils peuvent nous aider • Frameworks d'architecture • Générateurs de code

Slide 31: Les frameworks d'architecture Ce sont des bibliothèques tierces (.swc) • Pas indispensables... • Mais difficile de faire sans ! Les deux cas les plus communs : • Cairngorm • PureMVC

Slide 32: Cairngorm • Framework d'architecture Flex • Créé par Adobe Consulting • S'inspire des core patterns J2EE • Le plus utilisé Implémentation • Modèle : ModelLocator (Singleton) • Type d'événement : CairngormEvent • Pattern FrontController / Command • ServiceLocator • BusinessDelegate optionnel

Slide 33: Cairngorm Problèmes • Difficile de faire communiquer Commandes et vues • Risque de couplage des vues avec Cairngorm (event.dispatch()) • Pas terrible avec les Modules • Trop de Singletons => problèmes de tests • Documentation faible Notes • Beaucoup de ressources sur le Web • Générateurs de code • Cairngorm Extensions (Universal Minds)

Slide 34: PureMVC • Framework AS3 (pas Flex, ni Flash) • Créé par Cliff Hall • Existe pour d'autres technologies • Documentation de qualité et communauté active Implémentation • Modèle : Proxies • Contrôleur : Façade et Commands • Evénements : Notifications • Vues : Mediator

Slide 35: PureMVC Problèmes • Pas de DataBinding entre Modèle et Vues • Modèle événementiel non standard • Plus de travail de Cairngorm Souffre de son éloignement vis-à-vis du framework Flex

Slide 36: Conclusion • Privilégier une approche pragmatique • Ne pas essayer d'appliquer une solution avant d'avoir rencontré le problème • Ne pas avoir peur de la quantité de code : cela peut s'avérer rentable au final • S'appuyer sur des techniques qui ont fait leurs preuves plutôt que de réinventer la roue • Connaître un minimum Flex avant d'essayer les frameworks d'architecture • Commencer par Cairngorm avant PureMVC

Slide 37: Questions / Réponses David Deraedt - Flex My Day http://www.dehats.com Centre de formation Regart.net http://www.regart.net Remerciements Lovely Charts http://www.lovelycharts.com