Conseil n° 3 : Séparez votre VueModèle et votre Modèle de la logique d’accès aux données

Elles peuvent avoir à passer des appels pour l’enregistrement et le chargement des données, mais elles ne doivent pas être spécialisées dans la manière dont ces actions sont effectuées. C’est à ce moment que le modèle Repository entre en jeu. Le Repository est généralement considéré comme un moyen d’encapsuler les lectures et écritures vers une base de données pour le compte d’objets de Modèle de domaine, mais il ne s’agit pas forcément d’une base de données. L’approche est en fait ciblée plus sur le fait de masquer les détails de l’enregistrement et de la récupération des données de Modèle vers/à partir d’un référentiel persistant et moins sur un type particulier de référentiel persistant.

Séparez votre VueModèle et votre Modèle de la logique d’accès aux données

Pour Silverlight (ou tout autre client vers une application orientée service), cela signifie que vous pouvez probablement encapsuler la logique d’appel des services à l’intérieur d’un objet de modèle Repository. Par ailleurs, une fois la logique encapsulée à l’intérieur du modèle Repository, vous pouvez créer une interface pour ce Repository et du code correspondant dans votre application, IPersonRepository au lieu de WcfPersonRepository.

La création de cette interface Repository et le codage correspondant à ce type d’interface au lieu du type concret aboutit à une grande différence dans le fonctionnement de vos tests unitaires. N’oubliez pas que l’objectif consiste à tester des petites parties de fonctionnalités. Si vous testez la manière dont PersonViewModel gère les données récupérées via les appels à IPersonRepository, vous n’avez pas vraiment besoin d’appeler WcfPersonRepository. Vous pouvez créer une version factice de IPersonRepository qui retourne les données encapsulées. Désormais, vous testez uniquement la logique dans PersonViewModel au lieu de la logique pour PersonViewModel, WcfPersonRepository et le service WCF.

Le test résultant est ainsi nettement plus ciblé. Votre test et votre code applicatif sont maintenables car votre logique applicative est clairement séparée de la logique d’accès aux données, d’où un débogage facilité de l’application.