Data mapping (FR)

Contexte

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 « 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, et ce sans que leurs formats ne soient pas couplés avec la logique de récupération des données.

Pourquoi « mapper »?

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. En plus de complexifier le modèle, cela introduit un couplage entre la logique de sérialisation de données et la persistance de données ainsi que d’autres problèmes. Par exemple, il se pourrait qu’après la récupération de données à partir du service web, qu’un nouvel attribut soit 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 être muni du même attribut. Cependant, si on ne fait que déclarer cet attribut dans notre modèle, Moshi ne pourra pas convertir le résultat de la requête vers le service web. Une solution serait d’utiliser le mot-clé transient afin de signaler à Moshi d’ignorer cet attribut. Cependant, cela empêche la sauvegarde dans la base de données, car Room ignora également cet attribut.

Un autre désavantage est que la vue dépendra é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 du 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.

Quoi qu’il en soit, il serait préférable que le projet ait plusieurs représentations du modèle afin de réduire le couplage, minimiser les impacts des changements, etc.

Les modèles du projet