-
Notifications
You must be signed in to change notification settings - Fork 0
Data mapping (FR)
Le module Repository du projet a pour but de séparer la logique permettant de récupérer les données à partir de la base de données et de services web. Le module Repository agit en tant que médiateur entre différentes sources de données et retourne les données à l’application. Cela permet, entre autres, de centraliser la logique de récupération des données, d’éviter la duplication de code et d’améliorer la testabilité. Lors de la récupération des données, le module Repository effectue des opérations de mise en correspondance (mapping), c’est-à-dire qu’il transforme les données en différentes représentations afin que celle-ci puisse être utilisée par l’application.
Lorsqu’une donnée est récupérée à partir d’un service web, celle-ci est sous une représentation spécifique définie par le service web. Par la suite, celle-ci est convertie en POJO par Moshi. Pour ce faire, le modèle est une classe marquée par l’annotation JsonSerializable. De plus, les attributs peuvent être marqués par des annotations spécifiant leurs noms.
Ensuite, afin que cette donnée puisse être stockée dans la base de données à l’aide de la librairie Room, celle-ci doit être marquée par l’annotation Entity et munie d’un attribut défini en tant que clé primaire. Cela entraîne des problèmes tels que la complexification du modèle ainsi qu'un couplage entre la logique de sérialisation des données et la persistance des données. Par exemple, il se pourrait qu’après la récupération de données à partir du service web, qu’un nouvel attribut doive être introduit dans le modèle. Ce cas se présente lorsqu’on a demandé une donnée selon un attribut particulier et que le modèle retourné par le service web ne contient pas cet attribut. Après l’insertion de ce modèle dans la base de données, afin que celui-ci puisse être retrouvé par après, celui-ci doit avoir été préalablement muni du même attribut. Cependant, il ne suffit pas d'ajouter cet attribut à notre modèle, car Moshi ne pourrait pas convertir le résultat de la requête puisque celui-ci ne contiendrait pas cet attribut. Une solution serait d’utiliser l'annotation « Transient » afin de signaler à Moshi d’ignorer cet attribut. Cependant, cela empêcherait la sauvegarde dans la base de données, car Room ignorerait également cet attribut.
Un autre désavantage de l'utilisation d'un seul modèle est que la vue dépendrait également de la représentation fournie par le service web et utilisée pour la persistance. Cela signifie qu’un changement à la base de données ou au service web impacterait fortement celle-ci. Ce problème est encore plus important si la source n’est pas sous le contrôle des développeurs. Des exemples seraient un changement par rapport à l’API de Signets ou encore l'introduction de l'API de MonETS.
Bref, il serait préférable que le projet ait des modèles spécifiques pour le client, la base de données et le service web, et ce dans le but de réduire le couplage, minimiser les impacts des changements, etc.
| Utilisation | Description | Caractéristique | Emplacement |
|---|---|---|---|
| Service web | Représentations des données retournées par un service web | Munies du préfixe « Api » | response |
| Base de données | Représentations des données stockées dans la base de données | Munies du suffixe « Entity » | entity |
| Client | Représentations des données utilisées par le client | Dénuées de suffixe ou de préfixe | model |