Consolidate Caching (Dynamite-2013) and Cache (Dynamite-2010) namespaces (code dupe)
Opened this issue · 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.
After some initial review by @drdeteck and me, we feel that:
-
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.
-
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).
-
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.