I just started working on a new engagement with a major supermarket chain, and over the last week or so I've had the pleasure to convert an existing codebase "shell" from Cosmos DB to Sql Server and at the same time upgrade to the latest nuget packages and .NET 5 from Core 3.1.
This was my first experience with Cosmos Db. I didn't have a lot to do with Cosmos, but it was interesting to note that it allowed free form objects (JSON essentially) to be saved to the database. As I'd read, it saves the JSON "document" and it comes with indexes and "Partition Keys".
We decided to move to Sql Server because we couldn't develop locally with Cosmos DB. There is a dev Cosmos instance but only in Docker for Windows, which we couldn't use in our environment due to security settings. There's no real need to use Cosmos in this project, so the switch was sensible enough.
The Cosmos DB had an existing DbContext with a few DbSets mapped, along with some entities. Changing to Sql Server was essentially as easy as creating EntityConfigurations (IEntityConfigurationType<TModel>) for each of the models and removing the PartitionKey property from each model. I then removed any reference to the Comsos packages and started fixing.
Overall it was as simple as that - and done in less than a day. Admittedly it was a small project, but I was impressed with how simple it was.
This does open up the argument on how Entity Framework acts as the repository, or at least makes it redundant. Particularly when the "What if I want to switch databases" argument is raised.
