Fondamentaux d'architecture d'une application Flex

1
Fondamentaux d'architectured'une application Flex

• Adobe eSeminar - 06/06/08David DeraedtCentre
  Regart.net

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 (?)

3
Contraintes

• Constat Maintenance gt Développement
  initialMéthodes agiles cycles courts,
  itératifsFaciliter
• Modifications
• Tests / Débogage
• Travail en équipe
• Productivité

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)

5
Mise en oeuvre

• POO
• Encapsulation
• Polymorphisme
• Design patterns
• Architecture patterns

• Contexte technologique
• Flex RIA Couche présentation d'une
  architecture 3 tiers

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"

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, ...

8
Rich Internet Application
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 ?

10
Communication

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

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.gt
  Intérêt limité à de "petites" tâches
  individuelles - Upload de fichiers, création de
  fichiers, Proxies, etc...ougt JSON (typage
  des données)

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é

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 !

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 ?

15
 
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
• gt C'est la vue d'un MVC
• Ces vues peuvent elles être indépendantes ?
• Qui va s'occuper du reste (logique de
  l'application) ?

17
Indépendance des composants

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

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é

19
Un MVC côté Flex

•  

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"

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

•  

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, ...)

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

•  

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)
• gt Difficile de faire quelque chose de propre
  ET standard

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 ...)

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

•  

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

28
La couche métier

•  

29
Vue d'ensemble
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

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

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

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 gt problèmes de tests
• Documentation faible
• Notes
• Beaucoup de ressources sur le Web
• Générateurs de code
• Cairngorm Extensions (Universal Minds)

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

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

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

37
Questions / Réponses

• David Deraedt - Flex My Dayhttp//www.dehats.com
  Centre de formation Regart.nethttp//www.regart.
  netRemerciementsLovely Chartshttp//www.l
  ovelycharts.com