Serialization with Protobuf-net

[MichaCo]

Add another serialization option implemented using https://github.com/mgravell/protobuf-net.
Should work the same as the Json serialization

The is up for grabs for now. If someone wants to help, don't worry about the msbuild solution for now, I will take care of that. Create a new xproj under /src called CacheManager.Serialization.Protobuf-net

[rubaiyet-sadi]

Can I take this Issue?
Also how about moving Abstracting CaheItem as ICacheItem and both Serializarion.Json and Serialization.ProtoBuf-net projects can implement this

[MichaCo]

You mean JsonCacheItem.cs? CacheItem is already a base class in CacheManager.Core.
The JsonCacheItem is implementation specific, and should only be known to, for the Json serialization.
The protobuf-net version might need something similar but those items will never be shared with anything. So, no, there is no reason to abstract that I think.

Can I take this Issue?

Sure, go ahead and give it a try 😄

[jzabroski]

CacheItem is already a base class in CacheManager.Core

Sure, but it is not an interface, and the general question of why you need a base implementation is a good one.

Looking at the two current files:

• https://github.com/MichaCo/CacheManager/blob/dev/src/CacheManager.Serialization.Json/JsonCacheItem.cs#L6
• https://github.com/MichaCo/CacheManager/blob/dev/src/CacheManager.Core/CacheItem.cs

They're nearly identical in terms of the properties they support.

Why not make the following ICacheItem interface:

public interface ICacheItem<TValue> {
        /// <summary>
        /// Gets the creation date of the cache item.
        /// </summary>
        /// <value>The creation date.</value>
        DateTime CreatedUtc { get; }

        /// <summary>
        /// Gets the expiration mode.
        /// </summary>
        /// <value>The expiration mode.</value>
        ExpirationMode ExpirationMode { get; }

        /// <summary>
        /// Gets the expiration timeout.
        /// </summary>
        /// <value>The expiration timeout.</value>
        TimeSpan ExpirationTimeout { get; }

        /// <summary>
        /// Gets the cache key.
        /// </summary>
        /// <value>The cache key.</value>
        string Key { get; }

        /// <summary>
        /// Gets or sets the last accessed date of the cache item.
        /// </summary>
        /// <value>The last accessed date.</value>
        DateTime LastAccessedUtc { get; set; }

        /// <summary>
        /// Gets the cache region.
        /// </summary>
        /// <value>The cache region.</value>
        string Region { get; }

        /// <summary>
        /// Gets the cache value.
        /// </summary>
        /// <value>The cache value.</value>
        TValue Value { get; }

        /// <summary>
        /// Gets the type of the cache value.
        /// <para>This might be used for serialization and deserialization.</para>
        /// </summary>
        /// <value>The type of the cache value.</value>
        Type ValueType { get; }
}

This then simplifies the implementation of Type ValueType { get; } since it will always be TValue.

More importantly, by creating a concrete contract for the Type of TValue, you can create a "key-value registry" wrapper around CacheManager to ensure type-safe access to read/write keys-value pairs.

[MichaCo]

The point is that CacheItem is the ONLY base element used in CacheManager's logic. It also has some special things implemented.
I don't want it to implement an interface and potentially expose the interface instead of the concrete class through the ICacheManager interface (e.g. GetCacheItem).
That's not how the thing should work. I explicitly prevent people from implementing their own CacheItem and then maybe introducing bugs by not implementing everything... In those cases it is much better to have a base class and if you need to customize it, you can extend it.

The Json Serializer version has similar properties, sure, but the usage and intention is totally different.
It will never be stored in cache and will never be used by the CacheManager logic; it is just used to transport the information and data. I needed it for the Json implementation, but I'm pretty sure there could also be other ways to implement it without such an object.

I'm not even sure if you would even need something like that for the Protobuf implementation

[rubaiyet-sadi]

I agree with @MichaCo , I was thinking along the same lines as @jzabroski but then I realized for all the concrete implementation we have to decorate the attributes differently, so not much to gain on the specific implementations.

Another option is to inherit from a abstract class, but I think that would limit any specific CacheItem with no class inheritance.