dynamite icon indicating copy to clipboard operation
dynamite copied to clipboard

Consolidate Caching (Dynamite-2013) and Cache (Dynamite-2010) namespaces (code dupe)

Open taoneill opened this issue 10 years ago • 2 comments

Some caching helpers were added by @FranckyC and @yohanb in Dyn 2013 while I did the same under another GSoft.Dynamite.Cache namespace. Prefer using the Cache namespace if possible because it evolved to be a bit more generic (and to have one separate cache per security group) during our latest SP2010 project.

taoneill avatar Apr 04 '14 16:04 taoneill

After some initial review by @drdeteck and me, we feel that:

  1. The SessionCacheHelper is slightly misguided: a typical SharePoint install won't have SessionState enabled. Instead, use the normal CacheHelper (i.e. AppCacheHelper) and use a ParametrizedCachedKey with a prefix/parameter determined by the User's identity. After all, the SessionCacheHelper's sole purpose was to keep user-specific values in memory. If the SessionCacheHelper is used for its session lifecycle, we should use the dependency injection feature to target specific lifecycle for our objects.

  2. Everything related to CacheValue was made necessary by the new BinaryClone semantics @yohanb introduced (you can't BinaryClone a primitive value). Originally (and in Dynamite-2010 still), objects fetched from cache are mutable (i.e. they are NOT cloned or deserialized when fetched from cache) and the mechanism supports primitive values. Thus, to keep the model as simple as possible and to encourage memory sharing (always copying/cloning objects as they get fetched from cache gets expensive), all cloning when fetching from cache should be done OUTSIDE of the cache helper mechanism. The cache helper's responsibility should be to hold primitive values or object references ONLY. I.E. it should be possible to fetch an object reference from cache and to mutate that object (and if you do mutate that object, be sure to use proper locking/critical sections to support concurrent access and modification).

  3. The SET method was introduced to the CAcheHelper simply to get around the cloning. As mentioned above, objects fetched from cache should be mutable, so only CacheHelper.GET should be possible, to keep the programming model as simple as possible.

taoneill avatar Apr 04 '14 19:04 taoneill

We added [Obsolete] attributes everywhere in the GSoft.Dynamite.Caching namespace. We'll make a release for @FranckyC and @yohanb with those utilities still there, but they'll be gone in favor of the simpler GSoft.Dynamite.Cache namespace utils by the subsequent release.

taoneill avatar Apr 04 '14 20:04 taoneill