Starting out with MongoDb and C#
MongoDb, the document oriented database which allows us to store our domain objects/view model objects in a simple, scalable and performant manner. In this article I’m going to be discussing the basics of getting up and running with mongoDb and achieving the basic Create, Retrieve, Update and Delete operations.
Configuring & Running MongoDb
The process of setting up MongoDb really couldn’t be any simpler for what we’re trying to achieve with this post. First download MongoDb here, the version I’m working with in this article is 1.6.5, but the latest version should do. Unzip the zip file and locate mongod.exe, but before running mongod.exe make sure that the directory ‘c:\Data\db’ exists. This is where MongoDb will store it’s data files and while it is configurable, that’s beyond the scope of this post. Once you’ve confirmed the data directory exists you can go ahead and run mongod.exe, and with that we have a running instance of MongoDb.
The MongoDb .NET provider
There are various .NET providers for MongoDb available currently, the one I’ve chosen for the purposes of this article is, MongoDB-CSharp which although is still in beta has a nearly complete Linq implementation which is important to me.
The Code
To get started let’s have a look at how we first connect to, and disconnect from our instance of the mongoDb we’ve setup.
private static void ConnectToDb()
{
Mongo mongo = new Mongo();
mongo.Connect();
IMongoDatabase nbaTeamsDb = mongo.GetDatabase("NbaTeams");
mongo.Disconnect();
}
The first line here gives us a connection instance to the localhost instance of mongoDb, if we need to connect to a remote instance of mongoDb then the constructor can also accept a connection string.
Then we simply open the connection and call GetDatabase(), to retrieve the database we wish to be working with, if the database does not already exist then a new one will be created. Because we don’t need a schema, we don’t need to tell mongoDb anything about the objects we are planning to persist. Finally we just call Disconnect() to disconnect from our mongoDb instance.
Our Object Model
In the spirit of simplicity I’ve come up with a pretty basic object model of a Team which has a few attributes along with a collection of Players.
public class Team { public Oid Id { get; set; } public string City { get; set; } public string Name { get; set; } public IList<Player> Players { get; set; } }
public class Player { public int Number { get; set; } public string FirstName { get; set; } public string LastName { get; set; } public Position Position { get; set; } }
What’s interesting to us in this code is the type of the Id field on the Team object, Oid or Object Id is a mongo type which will allow the mongoDb service to assign unique identifiers to our objects. Without this field mongo would have no way of recognising whether our objects are new or have already been peristed when ask it to save one. ie. if an object is to be added or updated.
You will also notice that the Player object does not contain an identifier field, this is because in our simple example Players are not persisted on their own, but only as part of the Players collection on the Team object. Thus a Player cannot exist without a Team.
Preparing our Objects for Persistence
Before we talk about persisting our objects let’s first prepare them with some test data,
public static Team BuildUpCelticsTeam() { return new Team() { City = "Boston", Name = "Celtics", Players = new List<Player>() { new Player() {Number = 43, FirstName = "Kendrick", LastName = "Perkins", Position = Position.Center}, new Player() {Number = 5, FirstName = "Kevin", LastName = "Garnett", Position = Position.PowerForward}, new Player() {Number = 34, FirstName = "Paul", LastName = "Pierce", Position = Position.SmallForward}, new Player() {Number = 20, FirstName = "Ray", LastName = "Allen", Position = Position.ShootingGuard}, new Player() {Number = 9, FirstName = "Rajon", LastName = "Rondo", Position = Position.PointGuard} } }; } public static Team BuildUpLakersTeam() { return new Team() { City = "Los Angeles", Name = "Lakers", Players = new List<Player>() { new Player() {Number = 17, FirstName = "Andrew", LastName = "Bynum", Position = Position.Center}, new Player() {Number = 16, FirstName = "Pau", LastName = "Gasol", Position = Position.PowerForward}, new Player() {Number = 15, FirstName = "Ron", LastName = "Artest", Position = Position.SmallForward}, new Player() {Number = 24, FirstName = "Kobe", LastName = "Bryant", Position = Position.ShootingGuard}, new Player() {Number = 2, FirstName = "Derek", LastName = "Fisher", Position = Position.PointGuard} } }; }
Like I mentioned earlier, players only exist as part of a team. And notice that we haven’t had to initialise the Id fields because this will be automatically assigned by mongoDb as part of the persistence process.
Adding an Object to MongoDb
Let’s have a look at a simple example of saving new objects to the mongoDb data store,
private static void AddTeams() { Mongo mongo = new Mongo(); mongo.Connect(); IMongoDatabase nbaTeamsDb = mongo.GetDatabase("NbaTeams"); var teams = nbaTeamsDb.GetCollection<Team>(); var celtics = BuildUpCelticsTeam(); teams.Save(celtics); var lakers = BuildUpLakersTeam(); teams.Save(lakers); mongo.Disconnect(); }
What’s happening here is using the code we looked at earlier we’re connecting to our mongoDb instance and getting a reference to our database NbaTeams, if it already exists it will be retrieved and if not a new one will be created.
We then get a reference to the collection in which we want to persist our object, and since we’re persisting objects of type Team that is what collection we will retrieve. Then using the build up methods I mentioned earlier we’re populating our objects and to persist them we simply call Save() on our object collection passing the object to be saved as the parameter.
So as you can see it’s a simple process to persist our objects to mongoDb, we don’t at any time need to tell mongoDb anything about the type of objects we plan to persist, we simply need to retrieve a collection of the type of object we plan to persist and call Save().
Retrieving an Object from MongoDb
Retrieving persisted objects from mongoDb is as simple as querying a collection of objects using linq.
private static void QueryTeams() { Mongo mongo = new Mongo(); mongo.Connect(); IMongoDatabase nbaTeamsDb = mongo.GetDatabase("NbaTeams"); var teams = nbaTeamsDb.GetCollection<Team>(); //Example 1. var celtics = teams.Linq() .Where(t => t.City == "Boston") .FirstOrDefault(); //Example 2. var lakers = teams.Linq() .Where(t => t.City == "Los Angeles"); //Example 3. var teamsWith5Players = teams.Linq() .Where(t => t.Players.Count == 5); mongo.Disconnect(); }
In our first example here we are querying mongoDb for a single Team instance where the team comes from “Boston”. If more than one team is from the city of Boston then only the first object that mongoDb finds will be retrieved.
In our second example the result will be a collection of Team objects that come from the city of “Los Angeles”. That may be 0 or more.
And finally our third example will return a collection of 0 or more Team objects that contain exactly 5 players.
Updating an Object in MongoDb
If for example two of our Teams complete a trade where one player from Boston will go to Los Angeles and in return a player from Los Angeles will go to Boston, let’s have a look at how we would update our database to be consistent with the Team changes.
private static void UpdateTeams() { Mongo mongo = new Mongo(); mongo.Connect(); IMongoDatabase nbaTeamsDb = mongo.GetDatabase("NbaTeams"); var teams = nbaTeamsDb.GetCollection<Team>(); //Step 1. var celtics = teams.Linq() .FirstOrDefault(t => t.City == "Boston"); var lakers = teams.Linq() .FirstOrDefault(t => t.City == "Los Angeles" && t.Name == "Lakers"); //Step 2. var rayAllen = celtics.Players .FirstOrDefault(p => p.FirstName == "Ray" && p.LastName == "Allen"); var ronArtest = lakers.Players .FirstOrDefault(p => p.FirstName == "Ron" && p.LastName == "Artest"); //Step 4. celtics.Players.Remove(rayAllen); celtics.Players.Add(ronArtest); lakers.Players.Remove(ronArtest); lakers.Players.Add(rayAllen); //Step 5. teams.Save(celtics); teams.Save(lakers); mongo.Disconnect(); }
Firstly in step one we need to query mongoDb for a reference to each of the Teams who have been involved in the trade, secondly we query our Team objects for a reference to each of the Players who have been traded. Then we remove each Player from their original Team and add them to their new Teams, and finally we call Save() on the Team collection passing our updated Teams as parameters.
Deleting an Object from MongoDb
To delete a Team from our datastore, we simply retrieve a reference to the Team collection and call Remove() on it while using a lamda statement to specify the one or many Teams we wish to delete.
private static void DeleteTeams() { Mongo mongo = new Mongo(); mongo.Connect(); IMongoDatabase nbaTeamsDb = mongo.GetDatabase("NbaTeams"); var teams = nbaTeamsDb.GetCollection<Team>(); teams.Remove(t => t.City == "Los Angeles" && t.Name == "Lakers"); mongo.Disconnect(); }
In this example we specify that we want to delete any team that has a city of “Los Angeles” and a name of “Lakers”. With this level of detail, the statement would obviously only delete one Team from the database as there would never be two Teams with the same city and name. But if we were to remove the name from the statement, then any Teams (1 or more) that come from the city of “Los Angeles” would be removed.
Wrapping Up
I hope I’ve been able to demonstrate just how simple persisting and retrieving objects from mongoDb can be. Without having to worry as much about schemas and database technologies, we are free to focus more on our domain models and the complexity within our software.
Working towards decoupled code: Part 3 Ioc Containers
In my previous two posts I tackled a couple of methods which can be used to work towards decoupled code, the Service Locator and Dependency Injection. I also spoke about the limitations of a traditional service locator in that all objects that are dependent on other objects will need to become dependent on the service locator in order to decouple themselves from those dependencies. This is not ideal when we are trying to work towards decoupled code, but it was a good start.
An Inversion Of Control container can help us to get around the limitations of the traditional service locator by effectively build us the objects we require while taking care of the dependency injection I spoke about in my previous post.
For the purposes of this example I will be using the Unity Ioc Container, but this can easily be applied to any number of the containers out there today.
Readying Our Objects
By inverting the control of the objects our DecoupledClass object depended on in my previous post, we were able to remove the responsibility of constructing those dependencies out of the DecoupledClass object.
{
private ISalesRepository _repository;
private ISalesReport _salesReport;
public DecoupledClass(ISalesRepository repository, ISalesReport salesReport)
{
_repository = repository;
_salesReport = salesReport;
}
public void OutputReport(DateTime startDate, DateTime endDate, string outputPath)
{
var salesItems = _repository.GetSalesDetails(startDate, endDate);
_salesReport.PublishReport(salesItems, outputPath);
}
}
So as we can see, the objects that this class depends on are injected into it through its constructor, although this objected depends on ISalesRepository and ISalesReport, it is neither responsible for the concrete implementations which are to be used nor for construction of them. By inverting the control of these dependencies, we have already set up this object for use in an inversion of control container.
Configuring Our Container
At some point in our code we will need to configure our Ioc container. By configure I mean we need to tell it what implementations to use when an interface dependency is required. Ie, when we depend on the interface IAnimal, give us an object of type Dog.
Configuring the container should only happen once and generally should always be the first or one of the first things that occurs when an application starts up.
So in our very simple example, let’s create a new method called ConfigureIocContainer() which will be the first thing that is called when our application starts up.
public static void ConfigureIocContainer()
{
_container = new UnityContainer();
_container.RegisterType<IDecoupledClass, DecoupledClass>();
_container.RegisterType<ISalesReport, ExcelSalesReport>();
_container.RegisterType<ISalesRepository, OracleSalesRepository>();
}
So we’re just wiring up the container here by registering our concrete implementations with our interface declarations. By doing this our container will know that when an object is dependent on ISalesReport via constructor injection, a ExcelSalesReport should be constructed and injected into the dependent object. And as with the other registered implementations.
And in this way, we only have only one place were we’ll need to swap out our implementations should our requirements change.
Calling Our Container
Once we have wired up our container, in a perfect world we should only have to use it once. This is because if we have setup all our objects to accept their dependencies via constructor injection and we have configured our container with those dependencies, we should be able to just resolve our first class, and the container will take care of constructing and injecting everything else. That is to say that there should be no more than one object in our code base that has a dependency on our container.
So in our very simple example, when our application starts we configure the container, we resolve the very first object that we need, and we set the application of running,
{
ConfigureIocContainer();
var decoupledClass = _container.Resolve<IDecoupledClass>();
decoupledClass.OutputReport(Convert.ToDateTime(args[0]), Convert.ToDateTime(args[1]), args[2]);
}
The second line here, _container.Resolve() is where the magic happens. We’re telling our container we need an implementation of IDecoupledClass and the container is smart enough to go away and create one. It’s also smart enough to figure out that our implementation of IDecoupledClass is dependent on two other objects, implementations of ISalesReport and ISalesRepository. So it goes away and resolves those implementations from the container, constructs them and injects via the constructor of the DecoupledClass.
If our implementations of ISalesReport and ISalesRepository had dependencies of their own, which in the real world they most likely would, as long as the container was configured with them, they too would be automatically resolved and injected into their implementations.
So essentially, if we’ve written our objects in a decoupled manner, the Ioc container will be responsible for constructing the whole object graph representing our application.
Working towards decoupled code: Part 2 Dependency Injection.
In my previous post I spoke about what I consider to be coupled code and how it effects the maintainability and testability of a code base. I also spoke about one method of reducing code coupling in an effort to achieve our goals of maintanability and testability, the Service Locator.
While the service locator was partially successful in allowing us to achieve our goals, we also learned that it had some short comings, namely that it did not completely decouple our code, it merely replace one kind of coupling with another. As well as the fact that it could not deal with any of the more complicated dependency scenarios. For instance multiple levels of dependency, or a dependency having dependencies of its own.
Liskovs Principle of Substitution
The most important thing we achieved in my last post was that we extracted interfaces from our concrete types and had our dependent object reference our interfaces rather than our implementations. This has allowed us to comply with Liskovs Principle of Substitution, which states,
If S is a subtype of T, then objects of type T in a program may be replaced with objects of type S without altering any of the desirable properties of that program.
Put simply, this means that if we reference interfaces rather than concrete types in our code we’re able to swap our implementations in and out without having to change any of the code in the object that depends on them. So by defining our objects as interfaces,
private ISalesReport _salesReport;
We’re able to assign any implementation that inherits from these interfaces, without the referencing code being effected.
Our next step is some how passing a concrete implementation of these objects into our dependent object so that they can be assigned to these references. This is called dependency injection.
Dependency Injection
Injecting a dependency into an object which requires it removes the responsibility of constructing and controlling the lifetime of a dependency from the dependent object. This pattern is called Inversion of Control because the control of the dependency is inverted from the dependent.
There are three ways in which a dependency can be injected into any object, Constructor Injection, Property Setting Injection and Method Injection.
Constructor Injection is the most commonly used method of Dependency Injection and it requires that dependencies be passed into the constructor of a dependent object as parameters.
Property Setting Injection is probably the most problematic method of dependency injection because it requires that a dependency be assigned via a property setter. It’s problematic because a method call may fail if a dependent object has not yet been injected via the setter, at the very least it will require more code to check for the dependency with each method the requires it.
Method Injection requires that a dependency be passed into a method call as a parameter and that the dependency is only to be used within the scope of that method.
So let’s have a look at how we would write the CoupledClass from the previous post if we were intending to inject it’s dependencies, for correctness I have renamed this class in this post to DecoupledClass.
{
private ISalesRepository _repository;
private ISalesReport _salesReport;
public DecoupledClass(ISalesRepository repository, ISalesReport salesReport)
{
_repository = repository;
_salesReport = salesReport;
}
public void OutputReport(DateTime startDate, DateTime endDate, string outputPath)
{
var salesItems = _repository.GetSalesDetails(startDate, endDate);
_salesReport.PublishReport(salesItems, outputPath);
}
}
With this implementation we have achieved a truly decoupled class. As we can see our implementations are being injected via the constructor and assigned to our interface references and the code is completely implementation agnostic, we can swap in and out any implementations of ISalesRepository and ISalesReport we like without changing or effecting our dependent object.
You may also notice that our dependent object is also now implementing an interface so that it may be injected as an interface itself.
Although our dependent object itself has become completely decoupled, something must at some point be responsible for constructing it’s dependency and passing it in, this will have to happen right up the chain and will usually have to be the first thing that occurs when the application runs,
{
ISalesReport salesReport = new ExcelSalesReport();
ISalesRepository repository = new OracleSalesRepository();
IDecoupledClass decoupledClass = new DecoupledClass(repository, salesReport);
}
This will be fine for a small app such as this example, but it is completely unfeasible for large scale applications. But there are tools that can help with the complexity of dependency injection, in my next post I will be discussing the Inversion Of Control Container.
Working towards decoupled code: Part 1 The Service Locator.
This is the first of a three part series in which I will attempt to explain three methods I’ve used in the past to help me to achieve loosely coupled code.
What Is Coupled Code?
Code is considered coupled when an object is responsible for the creation and lifetime of the objects in which it depends on. For example, consider the following code,
{
private OracleSalesRepository _repository;
private ExcelSalesReport _salesReport;
public CoupledClass()
{
_repository = new OracleSalesRepository();
_salesReport = new ExcelSalesReport();
}
public void OutputReport(DateTime startDate, DateTime endDate, string outputPath)
{
var salesItems = _repository.GetSalesDetails(startDate, endDate);
_salesReport.PublishReport(salesItems, outputPath);
}
}
This is what I would consider to be highly coupled code. What we have is an object CoupledClass which depends on two objects, OracleSalesRepository and ExcelSalesReport, both of which are instantiated inside the dependent object itself.
The consequences of this directly effect the maintainability of the code. What if we were to change our data access strategy and migrated to Sql server. I think given this code, it would be safe to assume that direct coupling to the OracleSalesRepository would be speckled throughout our code base. In this case we would have to go through everything, ripping our our Oracle dependencies and updating our objects to reference the SqlSalesRepository object.
Another such consequence is testability. How are we expected to unit test our OutputReport method with it’s two hard dependencies, one hitting a database and the other hitting the file system. This is impossible to unit test using our current implementation.
Programming to Interfaces
The first step in decoupling this code is to create interfaces from which our dependencies can implement, these interfaces will simply expose the public methods commonly required.
{
void PublishReport(IEnumerable<ISalesItem> salesItems, string outputPath);
}
{
IEnumerable<ISalesItem> GetSalesDetails(DateTime startDate, DateTime endDate);
}
By declaring our interfaces and having our implementations inherit from them, we have taken the first step in decoupling our code, we are now able to make our initial declaration of our objects implementation agnostic.
{
private ISalesRepository _repository;
private ISalesReport _salesReport;
public CoupledClass()
{
_repository = new OracleSalesRepository();
_salesReport = new ExcelSalesReport();
}
public void OutputReport(DateTime startDate, DateTime endDate, string outputPath)
{
var salesItems = _repository.GetSalesDetails(startDate, endDate);
_salesReport.PublishReport(salesItems, outputPath);
}
}
So as we can see here we have been able to define our objects as interfaces, allowing them to reference any object that implements the same interface.
There is still a problem with this code. Although we have decoupled the initial declaration of these objects from their implementations, we are still coupled in the constructer as the responsibility still lies within the dependent class to instantiate it’s dependencies. We need to implement something that can take this responsibility from our class, preferably something centralized so that when we need to make a change, such as changing our data access strategy, we only need to make it one place.
The Service Locator
A hand rolled service locator will provide us with a centralized location to store our dependencies. It will allow us to register our concrete implementations against our interfaces in one place so that whenever, for instance, we need a ISalesRepository, the service locator will be able to construct and pass us the implementation which has been registered.
In order to implement our very simple Service Locator we’ll need to create one Static class, the Service Locator must be static so that it can be referenced as a singleton throughout our code base.
{
private static IDictionary<Type, Type> _container;
private static IDictionary<Type, Type> Container
{
get
{
if(_container == null)
_container = new Dictionary<Type, Type>();
return _container;
}
}
public static T Resolve<T>()
{
if(!Container.ContainsKey(typeof(T)))
throw new ArgumentException(
String.Format("Type: {0} is not registered in the Service Locator", typeof(T)));
Type type = Container[typeof(T)];
return (T)Activator.CreateInstance(type);
}
public static void Register<TInterface, TType>()
{
Container.Add(typeof(TInterface), typeof(TType));
}
}
In our Service Locator we have a singleton Dictionary which will store our type maps, and we also have two methods, Register which allows us to register type associations in our code, and Resolve that will resolve a type matching the specified interface and return a constructed instance of the resolved type.
In order to use our Service Locator, we first must configure it with our type mappings. That is, we want to register our interfaces relationships to our concrete objects so that when we ask the Service Locator for a ISalesRepository the correct implementation is returned.
The Service Locator is usually configured as part of the application startup via some sort of bootstrapper, and should only be configured once.
{
ServiceLocator.Register<ISalesReport, ExcelSalesReport>();
ServiceLocator.Register<ISalesRepository, OracleSalesRepository>();
}
So what we’re doing here is saying, whenever I ask the Service Locator for an implementation of ISalesReport, I want an instance of ExcelSalesReport returned.
This will allow us to take the responsibility to of constructing our dependencies out of the class which depends on them, thus removing any dependency to ExcelSalesReport and OracleSalesRepository.
{
private ISalesRepository _repository;
private ISalesReport _salesReport;
public CoupledClass()
{
_repository = ServiceLocator.Resolve<ISalesRepository>();
_salesReport = ServiceLocator.Resolve<ISalesReport>();
}
public void OutputReport(DateTime startDate, DateTime endDate, string outputPath)
{
var salesItems = _repository.GetSalesDetails(startDate, endDate);
_salesReport.PublishReport(salesItems, outputPath);
}
}
Now that we have removed the responsibility of identifying and constructing our concrete implementations out of the dependent class, we are afforded a great deal more flexibility when working with this class. We can easily swap in and out Mock implementations for Unit testing while changing our Data Access approach will be less of an ordeal that it would have been.
Problems With This Approach
While the Service Locator approach has been effective in removing our concrete dependencies from our dependent class, thus allowing us to achieve our goals of flexibility and testability, this approach comes with it’s drawbacks.
The first is that while we’ve removed two dependencies from our dependent object, we have introduced a hard dependency to the Service Locator wherever we require a dependency. So while our code is less coupled than what it was, it is still coupled, if only to our Service Locator.
The second drawback is using the call Activator.CreateInstance() to construct our dependencies inside the service locator. While this works fine in this example, what would happen if our dependencies had dependencies of there own, this solution would not satisfy this scenario.
Using Ioc to Inject Action Filters on ASP MVC Action Methods
I’m a big fan of the custom action filters ASP MVC gives us the flexibility to apply in our web apps. For instance I like that it keeps my code clean of excessive logging calls or whatever and that I can just place an attribute on the top of my Action Method to say, yes I would like this method logged like so,
public ActionResult Schedule(string team, int year)
{
var schedule = _repository.FetchSchedule(team, year);
return Format(schedule);
}
To me this makes my code much more pleasant on the eye as the logging implementation is kept outside of the method body, and at a glance into the method I can see exactly what’s going on without having to poke through anything else.
What bothered me about this was that what if I were to change my logging approach and implement a new logging action filter? I would have to go through all the action methods in my app and replace this attribute with something like say DatabaseLogger or FileSystemLogger. Because there is no immediately obvious way of inverting the control of these action filters I decided to put together an Injectable action filter that will allow me to inject action filters via an interface.
{
private IActionFilter _actionFilter;
public InjectableAttribute(Type filterType)
: this((IActionFilter)MvcApplication.IocContainer.Resolve(filterType))
{}
public InjectableAttribute(IActionFilter actionFilter)
{
_actionFilter = actionFilter;
}
public void OnActionExecuted(ActionExecutedContext filterContext)
{
_actionFilter.OnActionExecuted(filterContext);
}
public void OnActionExecuting(ActionExecutingContext filterContext)
{
_actionFilter.OnActionExecuting(filterContext);
}
}
What this will allow me to do is decorate my action methods with the Inject attribute and pass in an interface representing an IActionFilter that I can then ask my Ioc container to resolve for me.
So now I can decorate my methods like so,
public ActionResult Schedule(string team, int year)
{
var schedule = _repository.FetchSchedule(team, year);
return Format(schedule);
}
And depending on how I configure my Ioc container, whichever implementation of ILogRequest is configured will be resolved and used to deal with the request.