I started this because I got fed up with Azure Table Storage. It feels too complicated to me, and I thought it would be a good exercise to see if I could implement the experience I was looking for. This is a good way to see if the complexity is justified and to get a deeper understanding of the issues in play. Here's the kind of code I'm wanting to write:
var client = new CloudObjectsClient("myaccount", "apikey");
// save something to the cloud
await client.CreateAsync("my stuff/object1", new Something()
{
FirstName = "whoever",
LastName = "whatever",
Date = DateTime.Today,
Price = 234.34m
});
// get object from cloud
var obj = await client.GetAsync<Something>("my stuff/object1");I have an instance running here: CloudObjects. This is a bare-minimum work in progress at the moment, but it does do some stuff now. This site is currently stopped.
While reminiscent of things like MongoDB, Redis, Azure Cosmos DB and such, I don't see this being competitive in performance or scale terms. As usual, this is something I simply enjoy working on.
I have a PowerPoint where I walk through most of the solution here.
My solution has three core projects:
- CloudObjects.App a .NET Core web app using the API template. This uses a SQL Server backend and my Dapper.CX project for all the data operations.
- CloudObjects.Client the NuGet package, the part you install and use in your programs.
- CloudObjects.Models the model classes shared by the App and Client projects.
I do some seemingly oddball things with the Model project dependency. Instead of the App and Client projects having a project reference to the Model class project, I used linked source files, for example these. There are a couple reasons for this. One, it makes the Client NuGet package deployment easier. Project references aren't included in a NuGet package. So, I would need to release my referenced project as a separate package. This would complicate the release management, and I don't need more complexity. Two, linked source files work better when you have things like server side validation and auditing that require database connectivity. Using partial classes with clear dependency separation lets me keep the database dependency out of the Client project, where it doesn't belong. (The Client package never opens a direct database connection.) At the same time, I can ensure that Client and App projects are using the same model classes fundamentally.
There are two test projects Testing.App and Testing.Client. I had to separate them because of how the Model classes are linked in both the App and Client projects. If I had a single test project, then the Model classes would be linked twice, which would offend the C# compiler. Having separate test projects fixes that.
When you run the application locally for the first time, you should see this message on the home page that the "local database is missing." Click the button to create the local database and tables.
The code that creates the tables is here. It uses my ModelSync project.