Domain Driven Design with Web API extensions part 8: domain repository with MongoDb

Introduction

Some months ago we went through an updated series on Domain Driven Design starting with this post. We built a functioning skeleton project with EntityFramework as the backing store, a Web API layer as the top consumer, a loosely coupled service layer and a central domain layer with some logic.

In this extension series we’ll investigate how to implement the domain repository in a data store that’s markedly different from SQL Server. In particular we’ll take a look at the NoSql document-based MongoDb.

We could have picked any other data store type but I’m familiar with MongoDb from my work. There is a whole suite of NoSQL databases out there besides MongoDb. Some examples:

• Redis
• CouchDb
• Neo4j, a graph database
• riak
• RavenDb

The main goal is to show how the abstract repository interfaces we saw in the original series could be implemented in a different data store and how the new implementations can be wired up with StructureMap.

In addition, you may think that the data store of your application will never change in the future. It’s true that data migration and a complete switch from one data store type to another are very challenging tasks. However, that’s not to say that no-one has ever completed the transition. You can download a MongoDb white paper on this we page which gives you guidelines over how to transition from an RMDBS to MongoDb.

MongoDb

There’s a series on this blog dedicated to MongoDb starting here. MongoDb is evolving quite quickly so that series is probably already outdated here and there. I’ll try not to turn this extension series into a MongoDb tutorial as that’s not the main topic. We’ll only discuss what’s absolutely needed for this series. I’m planning to go through MongoDb again later on in 2016 anyway. I’m still assuming that you are completely new to MongoDb so I’m aiming to give a detailed presentation of the installation process and how to query the MongoDb database with the .NET driver.

MongoDb is a great alternative to traditional relational databases. I think it’s a great idea to explore it to enhance your skill set. Even if you’re a staunch relational DBMS advocate and think you’ll never use anything else for your data storage solution it’s still beneficial to know that there are other tools out there. Also, you can have have a mixed data storage strategy where you store some objects in a relational DBMS and some others in a document store depending on the objects’ nature and the advantages and disadvantages of each storage mechanism.

Also, MongoDb is not some small and obscure test database. It’s out there for real and a number of large companies such as BuzzFeed, MTV or eBay use it as their data store.

MongoDb terms

As hinted at above MongoDb is a document-based database. In SQL Server the records are stored in rows where each column usually represents a property of the object that the table describes. In MongoDb however, information is stored in JSON documents – or to be exact, in Binary JSON, i.e. BSON. Here’s an example from the MongoDb homepage:

{
"_id" : 1,
"name" : { "first" : "John", "last" : "Backus" },
"contribs" : [ "Fortran", "ALGOL", "Backus-Naur Form", "FP" ],
"awards" : [
{
"award" : "W.W. McDowell Award",
"year" : 1967,
"by" : "IEEE Computer Society"
},
{ "award" : "Draper Prize",
"year" : 1993,
"by" : "National Academy of Engineering"
}
]
}

Advantages

There are some key advantages of MongoDb compared to traditional “table-based” databases:

• Dynamic data structure with flexible schemas: you don’t need to define columns and tables. You can in fact store pretty much anything within the same collection
• Due to the lack of strict schemas data migrations become a lot easier too: if you change your domain structure, i.e. you business objects in code, the document will store the objects correspondingly. You can force a change in the schema through changing your custom objects automatically
• You don’t need separate tables to show relationships: the above JSON structure shows you that there’s no need for a separate “awards” collection, you can show the relationship directly within the document – there’s no need for foreign keys and constraints. If you extract a single item from a collection then you’ll immediately get its associated objects: order with all order items, rock band with all concerts, making it a breeze to perform operations on those linked objects
• MongoDb documents therefore allow storing your objects in an object oriented fashion which is sometimes difficult and awkward to solve in SQL Server with separate tables and keys. This point is probably the single biggest advantage of MongoDb; the JSON example above demonstrates how easy it is to store real objects and object graphs in MongoDb.
• Due to the lack of constraints such as secondary keys updating and deleting items will be easier: there’s no cascade delete, no orphans
• Speed: MongoDb is very fast and efficient in querying and inserting items in a collection

Disadvantages

All of the above is very well and good but there are couple of things that you need to be aware of if you’re coming from an SQL Server environment – which probably at least 95% of .NET developers do.

• Lack of professional tools: with SQL Server you can use SSMS for some very advanced GUI-based database operations, such as database profiling, SQL jobs, a query editor, IntelliSense and a whole lot more. There’s no equivalent in MongoDb. If you want to work directly with collections without one of the drivers – C#, Java, Php etc – then you’ll need to write your code in a console window or develop a custom solution yourself. There’s one visual tool though that you can use to improve the administration of your MongoDb database: RoboMongo
• As of writing this post MongoDb doesn’t support transactions
• Many developers will say that the lack of a schema is actually a disadvantage: you cannot associate objects through keys, you cannot force a compulsory data structure like “NOT NULL”
• No stored procedures
• Difficult to retrieve lost data

In the next post we’ll set up MongoDb locally.

View the list of posts on Architecture and Patterns here.