CategoryMongoDB

Unit testing MongoDB in C# part 3: the database factories

Welcome to the third article of the series!

Last time I was talking about the database context and at how I injected a Factory to create the repositories. Of course we could have injected every single repository in the cTor, but this way adding a new collection to the database would force too many changes.

Injecting just the factory instead allows us to create internally all the repositories we need, add new ones easily and of course makes our life easier when it comes to testing.

Let’s take a look at our Repository Factory interface:

as you can see, that’s very standard and easy. The implementation also is pretty straightforward:

A couple of notes on this:

  1. the RepositoryOptions class is just a simple Value Object encapsulating some details like the connection string and the name of the collection
  2. in the cTor we have a dependency on another Factory used to get a reference to the database. Why we do this? I guess you know the answer 😀

As you can see, this injected Factory also is very easy:

you can find the implementation here.

Next time: let’s write some tests!

Unit testing MongoDB in C# part 2: the database context

Hi All!

Last time I rambled a little bit about TDD and how to implement a very simple MongoDB repository.

This time I want to introduce you to my cool friend, DbContext. The basic idea is to have an interface exposing all the collection on your db, or, in our case, all the repositories. Take a look at this:

( I will leave to you the definition of the entities ). The implementation is pretty straightforward:

A couple of details worth noting here:
1) the repositories are exposed as interfaces and not as specific implementation, making tests easier to write
2) again, all the repositories are generated via a factory, injected directly in the ctor.

The Factory Pattern allows us to add more repositories without much hassle and, moreover, to inject a “fake” factory during our tests.

Next time we’ll discuss about how to implement a factory for our repo-needs 🙂

Unit testing MongoDB in C# part 1: the repository

Ok folks, this time I’ll talk/brag a little bit about the fabulous C# MongoDB driver and how you can write some testable code with it.

If you have come across this post, probably you already know what unit tests and TDD are so you can go directly to the code.

For those of you that have lived under a rock for the last 15 years or so, here are the words of a very wise man.

Take your time, I will be here.

 

 

 

Interesting concept, isn’t it?

Just because I like adding links to my posts, the amazing uncle Bob has a nice list of the “three rules” of TDD.

Although there might be cases where TDD is not advisable, or where is basically useless, it’s an essential tool that every developer needs to have at his disposal… so let’s get started!

The basic idea is to have an interface for everything. Yes, simple as that. DI at it’s finest, kids! Always remember to separate your concerns, avoiding  huge monolithic classes that do too much. Divide et impera.

We can start with this:

Small and easy. Just basic read and update operations, nothing else. You can find a sample implementation here, as you can see it’s a simple wrapper over the MongoDB driver, nothing else, but having the interface allows you to hide all the implementation details AND to eventually mock everything in your tests.

Enough for now, the new Star Wars movie is waiting for me !

Next time we’ll talk about factories and how to create a simple database context.

Pagination with MongoDB

In the last few months I have spent some time looking at the traffic stats for this blog and looks like this post is attracting a lot of visits, so this time I decided to write a couple of words about how to page query results from a MongoDB collection.

Let’s start from the very beginning, then! Here’s the code for connecting to the db:

at this point all you have to do is create a valid query (or just use {} to pick all the documents ), compute the number of items to skip and you’re almost done. Take a look at this gist:

As you may notice, paging is very similar to the normal Linq approach, using two methods, one for “skipping” the previous items ( details here ) and another for limiting the number of results to a fixed amount ( details here ).

A note on performance: skipping the items may become a very CPU intensive operation because the server has to scroll over all the items till the desired position. With large collections it is very important to plan your queries carefully and create your indexes accordingly.

As a bonus, the code shows also how to sort the items with an instance of IMongoSortBy and how to pick only a subset of the fields with IMongoFields, I guess I’ll post more on this in the next days.

© 2019 Davide Guida

Theme by Anders NorenUp ↑