Mise en cache des données et notification aux clients des modifications apportées aux données dans ASP.NET

Question

Nous envisageons d'apporter quelques modifications architecturales à notre application, ce qui pourrait affecter les technologies que nous utiliserons à la suite de ces modifications.

Le changement que je fais référence à ce poste est comme ceci:

Nous avons découvert que certaines parties de notre application ont des données et des services communs, donc nous avons extrait les dans un service Globalservices, avec ses propres données de base db. Maintenant, ce service aura probablement son propre cache, de sorte qu'il n'aura pas à récupérer les données de la base de données sur chaque appel. Ainsi, lorsqu'un client appelle un service qui met à jour des données, d'autres clients peuvent être intéressés par ce changement ou non. Maintenant, cela dépend si nous décidons de garder un cache sur les clients aussi. Cela signifie que si les clients auront leur propre cache local, ils devront être notifiés d'une manière ou d'une autre (et d'abord enregistrer les notifications). Sinon, ils recevront toujours les données du service GlobalServices.

J'ai besoin de vos conseils instruits ici des gars:

1) Is it a good idea to keep a local cache on the clients to begin with? 
2) If we do decide to keep a local cache on the clients, would you use 
    SqlCacheDependency to notify the clients, or would you use WCF for 
    notifications (each might have its cons and pros) 

Merci les gens du lot,

Avi

Answer 1

J'aime le son de votre SqlCacheDependency, mais je vais répondre à cette d'un autre point de vue comme j'ai travaillé avec une équipe sur un scénario similaire. Nous avons créé une base de données maîtresse et utilisé des déclencheurs pour créer des représentations XML des données modifiées dans le maître, et stockées dans une table TransactionQueue, avec un peu de méta-données sur ce qui a changé, quand et qui l'a changé. Les bases de données client vérifient périodiquement la file d'attente des éléments qui l'intéressent et traitent le fichier XML et mettent à jour ses propres tables si nécessaire.

Nous avons également fait la même chose en inverse pour le client pour mettre à jour le maître. Nous configurons des triggers et une table TransactionQueue sur les bases de données client pour renvoyer les données au maître. Cela à son tour mettrait à jour toutes les autres bases de données client lors du prochain sondage. La bonne chose à ce sujet est qu'elle est assez indépendante de la plate-forme client et de la structure des données client, nous avons donc été en mesure d'utiliser la méthode sur une gamme de systèmes hérités et tiers. L'autre bon point ici est que vous pouvez retirer n'importe laquelle des bases de données de la boucle (y compris le maître - par exemple, l'échec de la connexion) et les autres fonctionneront toujours correctement. Cela a bien fonctionné pour nous car notre base de données principale était derrière notre pare-feu d'entreprise, et les bases de données Web plus simples étaient assis avec notre fournisseur de services Internet. Il y a évidemment des inconvénients à cette approche, comme le risque de course, donc nous avons pris soin de l'ordre du traitement des transactions, du traitement des erreurs, du dédouanement, etc. Nous avons également construit une interface de gestion pour fournir une couche d'interaction humaine. a été changé dans le maître.

Bonne chance! Tim