2010-01-02 5 views
1

Dire que je l'ai Object qui a un membre de type objet B .. et l'objet B a un membre de type C. Objetsérialisation .NET et Caching question

Object change très rarement, mais est lu très souvent, alors que l'objet C le fait souvent. Il est logique de mettre en cache l'objet A, mais quand il est sérialisé pour aller dans le cache, il est évident que le graphe entier est sérialisé.

Scénario: L'objet A est lu dans la base de données et rempli. Variable de type L'objet C est accédé et chargé paresseusement. Par souci d'exemple, C.Status est référencé dans la logique métier et a la valeur ACTIVE. Je change A.Name pour être "nouveau nom", et commet à la base de données et à mon cache.

L'objet C (d'ailleurs dans le code) a son statut modifié en SUSPEND.

  • À ce stade dois-je invalider le cache de l'objet A? *

Si je fais:

Si (A.B.C.Status == ACTIVE) SendLotsOfMoney (A)

Cela passe, parce que le graphe entier est sérialisé. Si C.Status change fréquemment, je ne veux pas continuer à invalider le cache de A parce que je me réfère fréquemment à A.Name, A.Status etc, et je ne veux pas continuer à frapper la base de données.

Je suppose que mes options sont: 1) Avoir un drapeau dans l'objet à jour qu'il vient du cache, et force recharger toutes les dépendances la première fois s'il a et ils sont référencés (paresseux les charger à nouveau) . Ceux-ci peuvent provenir du cache de toute façon ... mais il y a encore beaucoup de données stockées inutilement dans mon cache alors.

2) Continuer à invalider le cache. Évidemment, si j'ai A.B.C.D.E.F.G.Status, et A.H.I.J.K.Status etc, alors je vais recréer A tout le temps?

3) J'Override OnDeserialization et faire ce qui est en (1)

4) Je passer outre OnSerialization et définir toutes les références à nul (ils sont paresseux chargés et ne sont pas stockées?)

I » Je suis intéressé d'entendre les réponses. Je penche vers 4

Cordialement!

+1

Tu ne violeras pas la loi de Demeter! – jason

+0

cela peut être vrai, mais je hérite d'un autre système et il y a des problèmes de performance en ce qui concerne les allers-retours à la DB – sjhuk

Répondre

1

Avez-vous un moyen de changer la référence à C dans A.B à null lorsque C change? Ensuite, plutôt que d'invalider tout A, vous devez simplement définir la référence C sur null et la charger à nouveau lorsque vous en avez besoin. Ou, vous pouvez mettre en cache C séparément de A et B. En A.B au lieu d'une référence à C, vous pouvez conserver une clé de cache. Vous pouvez alors invalider C quand vous en avez besoin, et utiliser la clé de cache pour récupérer et/ou charger paresseux,

0

Je pense que lorsque j'ajouterai l'élément dans le cache, je signalerai l'objet de données comme "BeenCached", puis lorsque l'objet a besoin de charger à nouveau les différentes propriétés, il vérifie l'indicateur de cache pour la première fois, il vérifie son indicateur ReloadedFromCache et le remplit (qui peut être repeuplé à partir du cache ou de la base de données).

Cela devrait fonctionner correctement.Je ne descends pas la route de sérialisation/désérialisation car les objets sont sérialisés/désérialisés dans d'autres endroits.