Domain Driven Design with Web API extensions part 16: testing the MongoDb repository in the DDD application

Introduction

In the previous post we implemented the ITimetableViewModelRepository interface in the WebSuiteDemo.Loadtesting.Repository.MongoDb project. We saw that the implementation was practically the same as in the EF repository layer. The only difference was due to details in the MongoDb query syntax.

In this post we’ll finish off this extension series to the load testing DDD demo project. We’ll wire up the MongoDb repository layer with the rest of the application.

Preparations

There are a couple of things we need to sort out first.

Open web.config of WebSuiteDDD.WebApi and add the MongoDb connection string to it:

<add name="MongoDbWebSuiteContext" connectionString="mongodb://localhost:27017"/>

This is the same as what we had in MongoDbDatabaseTester.

Next add a project reference to WebSuiteDemo.Loadtesting.Repository.MongoDb in the WebSuiteDDD.WebApi layer. Also, set WebSuiteDDD.WebApi as start up project in the demo solution.

Changes in StructureMap

Right now StructureMap will inject the EF implementations of ITimetableRepository and ITimetableViewModelRepository into the services that depend on them. This is declared through the following statements in DefaultRegistry.cs:

using WebSuiteDemo.Loadtesting.Repository.EF.Repositories;
... //code ignored
scan.AssemblyContainingType<TimetableViewModelRepository>();
... //code ignored

StructureMap will search through the assembly that contains TimetableViewModelRepository which at present is WebSuiteDemo.Loadtesting.Repository.EF. It finds the implementing classes in that project.

Therefore a logical step for the re-routing is to tell StructureMap to look elsewhere, namely in WebSuiteDemo.Loadtesting.Repository.MongoDb instead. We’ll proceed as follows:

In DefaultRegistry.cs comment out the using statement:

using WebSuiteDemo.Loadtesting.Repository.EF.Repositories;

You’ll see that the row…

scan.AssemblyContainingType<TimetableViewModelRepository>();

…won’t compile.

To fix it add the following using statement:

using WebSuiteDemo.Loadtesting.Repository.MongoDb.Repositories;

The code will compile. We have just told StructureMap to “forget” the EF project and consider the MongoDb project instead.

Start the mongod server in a command prompt and then the start the WebSuite demo application in Visual Studio.

At first StructureMap should complain:

No default Instance is registered and cannot be automatically determined for type ‘WebSuiteDDD.Infrastructure.Common.ApplicationSettings.IConnectionStringRepository’

The reason is that MongoDbRepository requires an IConnectionStringRepository and StructureMap hasn’t found anything suitable.

We have to declare the exact implementation type to be injected in DefaultRegistry.cs:

namespace WebSuiteDDD.WebApi.DependencyResolution
{
	using StructureMap.Configuration.DSL;
	using StructureMap.Graph;
	using WebSuiteDDD.Infrastructure.Common.ApplicationSettings;
	using WebSuiteDDD.Infrastructure.Common.Emailing;
	using WebSuiteDemo.Loadtesting.ApplicationServices.Abstractions;
	using WebSuiteDemo.Loadtesting.ApplicationServices.Implementations;
	using WebSuiteDemo.Loadtesting.Repository.MongoDb.Repositories;
	//using WebSuiteDemo.Loadtesting.Repository.EF.Repositories;

	public class DefaultRegistry : Registry
	{
		#region Constructors and Destructors

		public DefaultRegistry()
		{
			Scan(
				scan =>
				{
					scan.TheCallingAssembly();
					scan.AssemblyContainingType<TimetableService>();
					scan.AssemblyContainingType<TimetableViewModelRepository>();
					scan.WithDefaultConventions();				
				});
			For<IConnectionStringRepository>().Use<WebConfigConnectionStringRepository>();
		}

		#endregion
	}
}

Start the application again, navigate to /loadtests in the web browser and if all goes well then you should see one or more load tests printed on the screen. It can happen that the DB has no load tests in the default search period of 14 days in LoadtestsController.Get. In that case you’ll see an empty Loadtests array.

You can also test adding and updating load tests like we saw in this post. You should see that the load tests are added to and retrieved from MongoDb. You can then easily switch back to EF if you want by replacing the using statement in DefaultRegistry.cs like we did above.

That’s all folks. I hope you’ve all learnt something useful that you can use in your own projects.

View the list of posts on Architecture and Patterns here.