Dossier SQL Server : Débarassez-vous des dépendances de base de données dans le développement orienté tests (2/3)

Un moyen remarquable de séparer la méthode UsernameExists() du code d’accès à la base de données consiste à introduire une interface et à appliquer le modèle Repository. Le rôle de ce modèle est d’isoler la fonctionnalité de modèle de domaine (objet métier) de la fonctionnalité d’accès aux données. Un modèle Repository fournit une interface simple pour enregistrer et récupérer les objets métier, et pour encapsuler les détails d’implémentation du travail. Voici une conception d’interface Repository pour l’objet User.

Dans une application à n niveaux qui utilise le modèle de domaine et enregistre sur la base de données, il vous faut un moyen de distinguer un objet d’un autre. C’est ce que l’on appelle l’identité d’un objet. La valeur d’identité pour un objet est généralement identique à la colonne de clé primaire pour la table qui stocke les données.
Lorsque vous créez une application à n niveaux, essayez de faire en sorte que tous les objets utilisent la même propriété pour décrire leur identité. Cette approche permet d’avoir un modèle d’objet propre et cohérent. Vous pouvez appliquer cette cohérence en créant une interface qui permet d’accéder à la propriété d’identité pour vos objets. Dans l’exemple d’application de cet article, il s’agit de l’interface IInt32Id, laquelle définit une seule propriété nommée Id et désigne un entier.

Tous les objets de modèle de domaine implémentent IInt32Id, ce qui contribue à conserver une conception propre et cohérente pour vos référentiels. Afin de bénéficier d’une bonne réutilisation, une interface IRepository<T> définit les opérations CRUD pour tous les objets métier dans l’application. Si un objet métier a besoin de méthodes Repository absentes de IRepository<T>, vous pouvez créer une interface spécifique à l’objet et y ajouter la méthode. Dans le cas de la fonctionnalité UsernameExists(), une interface IUserRepository implémente IRepository<User> et possède une méthode GetByUserName().

Maintenant que vous avez défini les interfaces Repository, vous pouvez réusiner UserFacade afin d’employer cette interface pour l’accès aux données au lieu de l’objet UserDataAccessObject. Même si l’exemple de code ci-dessus est très similaire au code original, l’objet UserFacade ne se préoccupe plus de l’implémentation d’accès aux données utilisée. Tant que vous fournissez une instance de IUserRepository sur le constructeur, la méthode UsernameExists() a tout le nécessaire pour effectuer son travail. En masquant cette logique derrière une interface et en la passant au constructeur, vous avez l’opportunité d’utiliser une implémentation de substitution de IUserRepository.

Dans les tests unitaires, une simulation ou substitution (mock) est un objet qui implémente une interface et fournit une version simplifiée au lieu de l’implémentation complète que vous allez employer en production. Dans ce cas, vous pouvez passer un objet de substitution qui implémente IUserRepository et fournit la fonctionnalité de base de données en mémoire au lieu de faire appel à la base de données réelle.