Cairngorm (informatique)
Pour les articles homonymes, voir Cairngorm.
Cet article est une ébauche concernant l’informatique.
Vous pouvez partager vos connaissances en l’améliorant (comment ?) selon les recommandations des projets correspondants.
Cairngorm est un framework écrit en ActionScript 3. Il suit le motif de conception Modèle-Vue-Contrôleur.
Utilisation modifier
Ce framework facilite la tâche du développement d’une application en offrant un squelette de l’application, une sorte de guide qui permet au développeur de suivre une logique lors de la réalisation d’une application.
Architecture modifier
- Business : Cette couche va contenir toutes les informations concernant les services et les appels des procédures distantes. Elle est composée de deux types d’informations, les voici :
- Les déléguées : Cette couche est le magasin de services. Elle va contenir les définitions des méthodes distantes d’accès aux données. Elle consiste en une liste de classes auxquelles nous avons délégué la responsabilité d’encapsuler les appels des services distants.
- Les services locateurs : C’est l’annuaire de toutes les sources de données, on les appelle aussi les services distants. Chaque service possède un identifiant, un lien d’accès et d’autres informations qui permettent de le définir. Elles peuvent être un lien vers un fichier XML, un serveur de base de données…
- Command : Le pattern commande est l’implémentation des fonctionnalités de l’application, chacune dans une classe. Chaque commande aura une mission (charger une liste d’exercices par exemple) bien précise qu’elle doit exécuter et gérer la réception et/ou l’envoi du résultat.
- Control : Cette couche est basée sur le pattern FrontController. C’est une composition entre le modèle MVC et celui du Command. Il permet d’associer un événement à un type de traitement. Ce qui demande l’encapsulation des traitements dans des classes commandes où chaque commande possède une classe événement qui servira à son déclenchement. C’est un annuaire dans lequel nous allons lister tous les traitements possibles que l’application peut offrir.
- Event : Cette couche est celle qui s’occupe de la gestion d’événement et du transfert des données entre la couche présentation et commande. Par exemple, si nous voulons ajouter un nouvel exercice, le déclenchement de l’événement « ajouter exercice » doit être accompagné par une instance de l’exercice.
- Model : Dans cette couche nous allons centraliser les accès à nos structures de données. C’est un annuaire d’instances de nos classes objets. Cette couche se base sur le pattern Singleton qui nous permet de résoudre le problème « Comment m’assurer que nous avions bien une instance unique de tel objet ? ».
- View : Cette couche est la présentation des données pour l’utilisateur. Elle possède aussi sa logique de fonctionnement, elle s’occupe des contrôles des saisies et le déclenchement des événements. Elle s’occupe de l’acheminement des informations depuis l’utilisateur et la couche événement.
- Vo : Ce pattern « Value Object » (on l’appelle aussi « Data Transfert Object ») permet de définir la structure de nos objets que nous allons utiliser dans l’application. Il consiste en une classe qui définit un objet. Cette notion est prise de la programmation orientée objet. La structure de données dans ce pattern n’est pas une définition technique mais plutôt sémantique. Nous n’allons pas parler de tableau, chaîne de caractères ou entier mais plutôt professeur, classe, exercice, série… Les objets doivent avoir un sens. La nouveauté par rapport à la programmation orientée objet est la centralisation des objets dans une seule couche. Nos objets ne sont plus éparpillés un peu partout dans l’application selon leurs utilisations.
