• Share
  • Email
  • Embed
  • Like
  • Save
  • Private Content
Fondamentaux d'architecture d'une application Flex
 

Fondamentaux d'architecture d'une application Flex

on

  • 5,493 views

eSeminar for Adobe France, June 2008. (French)

eSeminar for Adobe France, June 2008. (French)

Statistics

Views

Total Views
5,493
Views on SlideShare
4,736
Embed Views
757

Actions

Likes
4
Downloads
112
Comments
0

4 Embeds 757

http://www.dehats.com 709
http://www.slideshare.net 45
http://www.linkedin.com 2
http://74.125.155.132 1

Accessibility

Categories

Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

    Fondamentaux d'architecture d'une application Flex Fondamentaux d'architecture d'une application Flex Presentation Transcript

    • Fondamentaux d'architecture d'une application Flex Adobe eSeminar - 06/06/08 David Deraedt Centre Regart.net
    • 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 (?)
    • Contraintes
      • Constat : Maintenance > Développement initial Méthodes agiles = cycles courts, itératifs Faciliter :
        • Modifications
        • Tests / Débogage
        • Travail en équipe
        • Productivité
    • 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)
    • Mise en oeuvre
      • POO
        • Encapsulation
        • Polymorphisme
        • Design patterns
        • Architecture patterns
      • Contexte technologique
        • Flex = RIA = Couche présentation d'une architecture 3 tiers
    • Rich Internet Application
      • Architecture 3 tiers       
       
      • 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"
      Rich Internet Application
    • 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, ...
    • Rich Internet Application
    • Rich Internet Application
      • Le client (RIA Flex) communique avec :
        • L'API du service (parfois, directement DAOs)
        • Les VOs / DTOs
      • Mais de quelle manière ?
    • Communication
      • Avec Flex, deux familles d'outils :
        • Communication temps réel
        • Communication RPC asynchrone
      • RPC :
        • HTTPService
        • WebService
        • RemoteObject
    • 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)
    • 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é
    • 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 !
    • 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 : ?
    •  
    • 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) ?
    • 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
    • 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é
    • Un MVC côté Flex
      •  
    • 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"
    • Un MVC côté Flex : Le modèle
      •  
    • 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, ...)
    • Un MVC côté Flex : Le contrôleur
      •  
    • 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
    • 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 ...)
    • Un MVC côté Flex : Le contrôleur
      •  
    • 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
    • La couche métier
      •  
    • Vue d'ensemble
    • 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
    • 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
    • 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
    • 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)
    • 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
    • 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
    • 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
    • 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