Une couche de référentiel nécessite-t-elle de ne pas dépendre des identifiants de base de données dans le reste du code ?

Question

L'idée de la couche de dépôt, telle que je la comprends, est que vous puissiez rapidement et facilement remplacer une solution par une autre. Supposons que je veuille passer de MySQL à MongoDB. Je n'ai qu'à me soucier d'écrire une nouvelle couche de dépôt.

Jusqu'à présent, tout va bien.

Le problème est que MySQL utilisera (très probablement, en pratique) des entiers comme clés primaires, et MongoDB des chaînes de caractères. Ou peut-être que je veux que ma couche de référentiel pointe vers un service web, et qui sait quel type d'identifiants ils utilisent...

Ainsi, afin de donner à ma couche de dépôt une interface à l'épreuve du temps, je ne peux pas avoir de méthodes comme celles qui suivent :

EmployeeRepository.getById(int id)

ou

EmployeeRepository.getById(string id)

Que faire alors ? Toujours utiliser une chaîne de caractères (ou un objet ? ??) et laisser la couche de dépôt la convertir comme elle le souhaite ?

Ou bien les modèles d'une application devraient-ils avoir leur propre schéma d'identification interne, totalement distinct du schéma d'identification de la base de données, et la recherche devrait-elle toujours s'effectuer sur la base de cet identifiant ? Quelque chose comme :

EmployeeRepository.getByInternalId(int id) 

Quelle est la meilleure pratique en la matière ?

Answer 1

Ainsi, la couche de référentiel, telle que je la comprends, permet de remplacer rapidement et facilement une solution par une autre

Non. L'idée est d'abstraire la couche de données pour réduire la complexité et le couplage du code. Au lieu de tout regrouper dans une seule classe, vous obtenez deux classes avec des responsabilités plus distinctes.

Le passage d'un type de couche de données à un autre n'est pas trivial, même si vous utilisez des référentiels.

Cependant. Vous pouvez décider d'utiliser un type de couche de données dans un référentiel (par exemple vanilla ADO.NET) et un autre type de couche de données dans un autre référentiel (comme Entity Framework). L'idée est que vous pouvez adapter vos référentiels à chaque cas d'utilisation spécifique. Et ce, sans affecter aucun autre code.

Le problème est que MySQL utilisera (très probablement, en pratique) des entiers comme clés primaires, et MongoDB des chaînes de caractères.

Vous n'abordez pas le problème de la bonne manière. Les utilisateurs de votre application utilisent-ils la clé ? Doit-elle être dans un format spécifique ? Ou bien les clés générées par la base de données sont-elles acceptables ? Dans ce cas, utilisez le format utilisé par la base de données.

Si vous devez passer de MySQL à Mongo plus tard, vous aurez encore beaucoup de travail à faire (comme passer des relations de table aux documents).