Have you ever had your main side project spin out a side project of its own? I don't know how often this happens with others but it is seems to be a reoccurring theme with my projects.

Before I explain what this side side project is, let me explain a little how I got here.

The original side project

For the last number of years I've been working on building my own analytics tools to help manage and analyse brands. This itself deserves its own post at some point in the future when I eventually launch it but for now, the important part is to know a little about how development progressed with it.

My original concept for this was to be a PHP/MySQL site based around a little-known framework called SilverStripe. Should have been easy to build as it is one of the main technology stacks I use to build websites for clients. The further I went into development though, the further it didn't feel like the right technology for the job.

So what was PHP/MySQL changed to C#/MySQL - not exactly the most natural duo. Not long after that, for similar reasons as before, I changed again to C#/SQL.

Because I must just enjoy rewriting code, I changed again - this time, now C#/MongoDB.

These changes weren't just for kicks - it was the build up of little things along the way that made me want to do each of these changes. With the side project now using C# and MongoDB, this brings us to today.

C# + MongoDB = MongoDB C# Driver?

My experience with C# and databases have primarily been around the good ol' Linq2SQL interface which for the most part has done what I've needed to without issues. That said when I was working with C#/SQL for that original side project, I came to love Entity Framework - particularly the "Code First" experience and how you interact with collections.

An example of an EF "Code First" approach:

public class Person
{
    public int Id { get; set; }
    public string Name { get; set; }
}

public class MyContext : DbContext 
{
    public MyContext() : base() { }
    public DbSet<Person> People { get; set; }
}

...

using (var ctx = new MyContext())
{
    var entity = new Person() { Name = "James" };
    ctx.People.Add(entity);
    ctx.SaveChanges();           
}

MongoDB has a fully-featured C# driver and can probably do anything you want with the database. To me though, its downside is the API interface to it. In comparison to above, interfacing with the driver looks more like this:

public class Person
{
    public ObjectId Id { get; set; }
    public string Name { get; set; }
}

...

var client = new MongoClient("mongodb://localhost:27017");
var database = client.GetDatabase("foo");
var collection = database.GetCollection<Person>("bar");

collection.InsertOne(new Person { Name = "James" });

Now that is not an inherently bad API or anything, it just wasn't how I liked dealing with databases. What I really wanted was that Entity Framework interface but with a MongoDB backend.

If you're an Entity Framework Core fan, there does seem to be people working on proper MongoDB providers for it however back when I started working on this, that was not available. In addition to that though, my original side project is still stuck in .NET Framework, not Core.

So what did I do? I came up with an original name for my MongoDB "Entity Framework"-like library and got to work.

MongoFramework

Derivative is the new original

It may not be the first piece of code I have published for the world to see but it is probably the one that is most important to me right now.

What I wanted to build was a basic wrapper for the official MongoDB C# driver, making it feel like I was working with Entity Framework. Once I got the basics working, that is when I wanted to start being clever.

That MongoDB C# driver is good but there are some things that were cumbersome out-of-the-box. For example, performing document (aka. entity) updates required you to either use this builder/filter system and specify the keys and values that you updated OR you replace the whole document. Not liking either option, I set to build change tracking and support diff-updates in MongoFramework so you the developer doesn't need to worry.

Another example was how there is no "changeset" support in the official driver - the second you call InsertOne, it has sent that through to the DB. After a few iterations of changeset support in MongoFramework, it can now do a single BulkWrite call with all the changes in a particular MongoDbSet.

Still a Work-In-Progress

Like many side projects, MongoFramework is still a work-in-progress. There are many more features I want to add like GridFS, async reads and DB transaction support.

Even with MongoDB providers now available in EF Core, I think MongoFramework still has its place - if not in your next project, it has a place in my heart. ❤️