Pour faire suite à l’article d’Andew Trice sur l’architecture des RIA (Rich Internet Application), et du fait de ma découverte de Lovelycharts, je ne peux m’empêcher de dessiner des diagrammes à la moindre occasion. J’ai donc décidé de vous faire partager mon expérience de l’architecture dans Flex.

Gardez à l’esprit que je ne prétends pas entrer dans le détail dans ce document mais que je souhaite simplement fournir une vue d’ensemble sur les bases de l’architecture RIA. La plus grande partie de cette réflexion provient à la fois de mon expérience personnel et des formations Flex menée chez Regart.net; cette réflexion est donc bien plus une approche pragmatique que détaillée.

Les bases de l’architecture serveur d’une RIA

Afin de simplifier au maximum le propos, nous définirons qu’une application Internet riche dont la partie cliente est riche (on évoque souvent le terme d’application Web 2.0) basée sur des technologies telles que AJAX, Flex, Silverlight ou JavaFX. La majeure partie des applications sont 3-tiers, c’est-à-dire qu’on peut distinguer en leur sein 3 composants essentiels qui sont le plus souvent assimilés au modèle de conception MVC (pattern MVC) :

• le Modèle, où sont fournies les données
• la Vue, qui est une représentation graphique des données et qui reçoit les interactions utilisateur
• le Contrôleur qui gère et contrôle les échanges entre la vue et le modèle afin de mettre à jour celui-ci

Voici un schéma simple :

Dans un contexte d’application web, le modèle est représenté par la source de données, le contrôleur est le serveur d’application et la vue est la partie cliente.

Dans le cas d’une RIA Flex, le Contrôleur peut prendre la forme d’un service (ou objet métier) sur le serveur d’application. Celui-ci lit et met à jour la base de données (le Modèle) quand il en reçoit la demande de la part de l’application cliente Flex (la Vue) qui elle-même affiche la Base de données à l’utilisateur.

L’architecture du serveur d’application peut varier d’une simple page ou script à une architecture complexe. Un modèle de conception très commun est souvent implémenté dans ce genre de cas, il s’agit du pattern « Objets d’Accès aux Données » (Data Access Object – DAOs). Le service délègue à des objets autonomes la gestion de l’accès aux données, donc les actions d’ajout, lecture, suppression, modification ou CRUD acronyme de Create, Read, Update, Delete. Par la suite ces objets retournent les résultats sous forme d’objets de transfert de données qui sont en fait une représentation sous forme d’objets de la base de données. Ces objets sont appelés plus couramment Value Object car ceux-ci représentent un enregistrement de la base de données. Ce sont ces Value Object que le service recevra, manipulera et renverra vers la partie cliente (la vue).

Avec des serveurs d’applications J2EE, la couche métier dans laquelle on situe les services est gérée par des frameworks comme « Spring ». Celui-ci peut communiquer avec des DAOs situés sur des couches persistantes. Ces couches persistantes peuvent être manipulées via l’utilisation d’ORM (Object Relational Mapping) comme Hibernate. Le rôle d’un ORM est simplement de traduire un modèle de type SQL en modèle Objet.

Avec des serveurs d’applications PHP, Zend ou Cake PHP peuvent jouer le même rôle.

Dans le monde.NET world, de ce que je sais, des outils équivalents existent via ADO.NET ou encore une fois Hibernate.

Mais l’application cliente Flex n’a finalement pas à se soucier des détails de l’implémentation du contrôleur. La manière dont sont gérés les requêtes et les retours serveur ne concerne en rien l’application Flex elle-même, exactement de la même façon qu’une vue n’est pas sensée savoir ce que fait le contrôleur en interne. Elle a juste à savoir comment communiquer avec lui.

Pour résumer, le client Flex devra communiquer avec un service distant qui attendra et retournera notamment des Value Objects. Si vous êtes développeur Flex, vous aurez seulement à connaître l’adresse du service ainsi que l’API qui contient les méthodes et parfois des Value Objects.

Bien sûr, vous aurez à choisir une façon de communiquer avec ce service. C’est précisément ce que nous allons étudier dans la partie 2 de cette série.