Architecture de l'application mobile
Un grand merci à Max Bonbhel et Mathias Seguy pour ce cour très instructif.
L'architecture de l'application mobile est décrit par la figure suivant :
Chaque couche a un cahier des charges précis:
La couche IHM contient l’ensemble des écrans et se scinde en plusieurs sous-packages.
De la même manière qu’une application hiérarchise ses vues, cette hiérarchie doit se retrouver dans vos packages. Une application possédant toutes ses vues au premier niveau de son package ui est « a pain in the ass ». Il faut penser à la maintenance, à l’évolutivité et au coût d’apprentissage pour les nouveaux entrant sur le projet.
Ainsi, il faut structurer votre couche ui en la scindant en autant de partie que d’écrans et chaque sous-package se scinde en sous-vues.
Le deuxième concept fort est la séparation entre l’affichage des objets et leur gestion. La partie view a à charge l’affichage et la récupération des inputs utilisateur, la partie model se charge de la gestion des objets affichés. Cette séparation permet de ne pas avoir de code métier dans ses vues, de bien séparer les responsabilités et surtout d’avoir des classes propres (pas un classe vue de type poubelle de 1000 lignes ou s’entremêlent affichage des objets, gestion du cycle de vie, gestion des objets, appels aux services..). C’est un modèle de type M-(VC) pour Model-(View-Controller) spécifique à la construction d’IHM. C’est le pattern que je préconise.
Dans la couche IHM, les vues connaissent les autres Vues et leur modèle. Les modèles connaissent leur vue et les autres modèles. Attention, les modèles ne connaissent que les modèles qui dont ils dépendent (pas tous les modèles). Idem pour les vues. La plupart du temps le conteneur connait le contenu (pour les modèles comme pour les vues). Deux éléments au même niveau ne sont pas censés se connaitre. La relation Modèle-Vue est de
La couche services contient une ensemble de package service métiers (qui découlent directement des use-cases identifiés ou presque). Chaque package va contenir plusieurs classes qui permettent d’effectuer le traitement.
Chaque package doit être considéré comme une brique à part entière indépendante des autres. Elle doit posséder une façade (interface): Les méthodes qu’elle propose à l’IHM, qu’elle expose.
Tous les appels provenant de l’IHM doivent être sur les classes façades. Ce sont ces classes qui reventilent à l’intérieur du service les appels. Ces classes implémentent les interfaces et seules ces interface sont connues par la couche IHM.
La couche COM (communication) prend en charge l’accès aux données et services déportés sur un serveur web. Elle prend en charge la communication avec l’extérieur. Cela peut-être via le bus Http, un bus Corba, des services REST, un ESB… Bref, elle a à charge la communication avec quelque chose d’autre.
Comme les autres couches, elle expose ses services au travers de façades (interfaces). On ne doit pas spécifier le type de communication mais le service rendu.
La couche COM possède un sous-package qui contient la partie technique de la communication (ouverture de la session, encapsulation générique des objets, mise en place du bus …) qui n’est connue que par les classes de la couche COM. Ce sous-package est transverse à cette couche et factorise le traitement technique.
La couche DAO (Data Access Object) permet d’accéder aux objets métiers. Elle contient donc la plupart du temps les classes qui permettent d’encapsuler l’accès à la base de données. Comme pour la couche service, la couche DAO n’exposent ses services qu’au travers d’interfaces.
Elle possède aussi souvent des classes « utilitaires » qui factorise le dialogue avec la base de données (ouverture de session, gestion du cache, requêtes génériques …)
Chaque classe de la DAO exposent les méthodes CRUD (Create, Read, Update, Delete) mais aussi des méthodes spécifiques, exemple: getAllHumanIn(String ZipCode).
Elle contient :
- Les objets métiers
- Le traitement des exceptions
- Les méthodes utilitaires (Log, Tracker,…) Et c’est tout. La couche transverse est connue de tous mais ne connait personne.