Problem In some scenarios engineers might want to use a custom JSON serializer for documents stored in CosmosDB. Solution In CosmosDBV3 .NET Core API, when creating an instance of CosmosClient one of optional setting in CosmosClientOptions is to specify an instance of a Serializer . This serializer must be JSON based and be of CosmosSerializer type. This means that if a custom serializer is needed this should inherit from CosmosSerializer abstract class and override its two methods for serializing and deserializing of an object. The challenge is that both methods from CosmosSerializer are stream based and therefore might be not as easy to implement as engineers used to assume - still not super complex. For demonstration purpose as or my custom serializer I'm going to use Netwonsoft.JSON library. Firstly a new type is needed and this must inherit from CosmosSerializer. using Microsoft.Azure.Cosmos; using Newtonsoft.Json; using System.IO; using System.Text; /// <
Problem statement We all want to write clean code and follow best coding practices. This all engineers 'North Star' goal which in many cases can not be easily achievable because of many potential difficulties with converting our ideas/good practices into working solutions. One of an example I recently came across was about using ASP.NET Core and Entity Framework 5 to store Enum values in a relational database (like Azure SQL). Why is this a problem you might ask... and my answer here is that you want to work with Enum types in your code but persist an integer in your databases. You can think about in that way. Why we use data types at all when everything could be just a string which is getting converted into a desirable type when needed. This 'all-string' approach is of course a huge anti-pattern and a bad practice for many reasons with few being: degraded performance, increased storage space, increased code duplication. Pre-requirements 1. Status enum type definition