J'ai une application qui interroge un magasin de données local (actuellement supporté par un fichier XML), en utilisant Linq to Objects. Périodiquement, un autre thread dans l'application interrogera un serveur distant pour les données mises à jour et, s'il existe, téléchargera toutes les données distantes, les désérialisera et remplacera les objets locaux par des fichiers désérialisés avant d'enregistrer le nouveau XML sur le disque.Entity Framework/Architecture de synchronisation externe
J'ai décidé de remplacer le fichier XML par une base de données SQLite, et j'ai l'intention d'utiliser Entity Framework pour interagir avec lui. Cela m'a incité à revoir la façon dont les changements externes sont appliqués, et j'ai décidé que seules les données où la propriété updated_at des entités distantes est plus récente que l'entité locale seront mises à jour (plutôt que l'approche actuelle de remplacement de l'ensemble des données Je dois donc écrire une méthode pour télécharger les changements externes et mettre à jour ou insérer les entités pertinentes dans la base de données SQLite. Ce que je ne comprends pas est où, en termes architecturaux, cette méthode devrait s'asseoir. Ma pensée (potentiellement naïve) est qu'une méthode UpdateFromRemoteObjects<T>(List<T> updatedItems) générique pourrait s'asseoir dans la classe DbContext, et accepterait une liste d'entités et mettrait à jour le DbSet approprié. Mais cela semble être trop couplé au DbContext. Dois-je utiliser un référentiel pour fournir une couche pour implémenter cela? Ou est-ce qu'une autre architecture d'application est plus appropriée?
Eh bien, vous avez écrit que vous avez déjà des questions dans votre projet. Où sont-ils placés dans votre code? – Leron