Nous utilisons actuellement Entity Framework comme ORM dans quelques applications Web, et jusqu'à présent, cela nous convenait bien car toutes nos données sont stockées dans une seule base de données. Nous utilisons le modèle de référentiel et avons des services (la couche de domaine) qui les utilisent et renvoyons les entités EF directement aux contrôleurs ASP.NET MVC.
Cependant, une exigence est venue d'utiliser une API tierce (via un service Web) qui nous donnera des informations supplémentaires concernant l'utilisateur dans notre base de données. Dans notre base de données d'utilisateurs locale, nous stockons un ID externe que nous pouvons fournir à l'API pour obtenir des informations supplémentaires. Il y a beaucoup d'informations disponibles, mais pour des raisons de simplicité, l'une d'elles concerne l'entreprise de l'utilisateur (nom, responsable, chambre, titre du poste, emplacement, etc.). Ces informations seront utilisées à divers endroits dans nos applications Web - par opposition à être utilisées dans un seul endroit.
Ma question est donc la suivante: quel est le meilleur endroit pour remplir et accéder à ces informations? Comme il est utilisé à divers endroits, il n'est pas vraiment judicieux de le récupérer sur une base ad hoc partout où nous l'utilisons dans l'application Web - il est donc logique de renvoyer ces données supplémentaires à partir de la couche de domaine.
Ma pensée initiale était juste de créer une classe de modèle wrapper qui contiendrait l'entité EF (EFUser), et une nouvelle classe 'ApiUser' contenant les nouvelles informations - et lorsque nous obtenons un utilisateur, nous obtenons l'EFUser, puis les informations supplémentaires informations de l'API et remplissez l'objet ApiUser. Cependant, bien que ce soit bien pour obtenir des utilisateurs uniques, cela tombe lorsque vous obtenez plusieurs utilisateurs. Nous ne pouvons pas atteindre l'API lors de l'obtention d'une liste d'utilisateurs.
Ma deuxième pensée a été simplement d'ajouter une méthode singleton à l'entité EFUser qui renvoie l'ApiUser, et de la remplir en cas de besoin. Cela résout le problème ci-dessus car nous n'y accédons que lorsque nous en avons besoin.
Ou la dernière pensée était de conserver une copie locale des données dans notre base de données et de la synchroniser avec l'API lorsque l'utilisateur se connecte. C'est un travail minimal car c'est juste un processus de synchronisation - et nous n'avons pas la surcharge de frapper la base de données et l'API chaque fois que nous voulons obtenir des informations sur les utilisateurs. Cependant, cela signifie stocker les données à deux endroits et signifie également que les données sont obsolètes pour tout utilisateur qui ne s'est pas connecté depuis un certain temps.
Quelqu'un a-t-il des conseils ou des suggestions sur la meilleure façon de gérer ce type de scénario?
it's not really sensible to fetch it on an ad-hoc basis
-- Pourquoi? Pour des raisons de performances?