Part 1 – Summary of the Solution (Click Here)
Part 2 – The Solution
In this Post I’ll examine the components that make up the architectural solution described in my previous post in more detail up to the API / Controller level. If you want a copy of the complete code then don’t hesitate to contact me on the About Section of my blog and I’ll send you a copy.
Ok so let’s start at the bottom with the database. Well there is no database, not yet anyway. In my example I have used the Code-first approach which allows me to describe my model in code, from which Entity Framework will construct the database. Knowing this lets have a look at my model project;
I am using the common Blog Model. Keeping it simple, a Blog can contain many Posts and a Post can contain many Comments.
For this tutorial is not necessarily important to know what properties these objects contain but rather that they will reflect tables within our database and act as container objects to pass information around our system. However here is the code for the Post Class just so you have an idea of how it is constructed:
The Post Model Object
Remember that Entity Framework has the job of trying to convert C# model classes to the database and so it’s wise to give it as much information as possible to give it a helping hand. I’ve demonstrated this by adding an annotation to the Title Property and creating references back to Parent objects e.g. BlogId, Blog etc. which can be used by Fluent API (Not shown in this post) to enforce relationships between the data objects. I have also created the Comments collection as Virtual. This will ensure that the Entity Framework will not initialise the Comments collection until the data is specifically requested, improving performance.
Once we have our model classes we need to implement the repository layer to provide consistent data access. To provide the consistent data access I created a new project (to contain my interfaces) which contains an IRepository Interface;
This provides us with a generic interface which will accept an object from our model project and describe the data access actions that will be available to our application, e.g. retrieving records, updating records and adding a new record etc. By implementing this interface we have a standard set of actions that can be performed on our database model (consistency). If a model object needs to extend this set of actions, then we just create another repository interface which implements IRepository and includes the extra method signatures. For example check out IPostRepository in this example which adds an extra method to return the number of comments associated with a Post;
Following on from this we need to create the concrete implementations of the repository classes. This is done within another project which is essentially our data layer. I have created a class named EFRepository which implements IRepository. This will be our base data access class and every object in our model will implement the functionality within this class as a minimum;
We will also need implementations for extended repository interfaces such as the IPostRepository created earlier;
As in this instance we are using the Entity Framework, the repositories will access the database via the DBContext. You will notice that in the EFRepository class we create an instance of this DBContext in order to perform operations of the database. When developing against the Entity Framework using the Code-First approach you must create a Context Class which implements DBContext to identify the data objects which will be made available via the DBContext. Here is an example of the Context class I created for this project named BlogDBContext;
By now we have described our model objects and created our repositories to allow us to perform data persistence actions on the database objects that these represent. The next step is to implement the Unit of Work Pattern. This requires that we create a Unit of Work class which will provide a single point of access to our repositories and a method to persist changes to the database as a single transaction improving efficiency and reducing concurrency problems.
So what does the Unit of work class look like? Well if we examine its interface it simply exposes the repository objects and a single method to persist any changes back to the database. That’s it simple.
And the concrete implementation of the UnitOfWork class would look like this;
The key things to point out here is that firstly when we invoke the Unit of Work class we also create a new instance of our DBContext. By wrapping the DBContext within the Unit of Work we can submit our changes within a single update request and dispose of the context once the request is complete. We also have the advantage of performing atomic transactions, for example if one object fails to update when updating multiples objects within the database then we can rollback all objects to their original state reducing data inconsistency issues.
Another important point is that access to all repositories are available within this class and that also our context can be configured from this class. If there was suddenly a business requirement to move to another database platform which used different data access technologies e.g. nHiberate, then we could create another Unit of Work class and substitute it for this one without breaking the logic and UI layers. The advantages of a decoupled system!!
The final stage is to implement the Unit of Work into our business layer or in the case of this post our controllers within our API as I created a MVC application.
A sample controller Class using the Unit of Work
In this example I have created a quick controller class which when instantiated creates an instance of the Unit of work. This in turn will create an instance of our DBContext and out repository classes. As a result we instantly have available all the objects from our model and the operations associated with that model via the repository interfaces e.g. GetAll(), Remove(entity), Add(newEntity) etc. and in the case of the Post object GetCommentCount() which was implemented via the IPostRepository.
The only bit of code in this controller you might be querying is the constructor which seems to accept an instantiated unit of work object, in this case of type IWebTemplateUoW. This is because the Unit of Work Object is created for the controller using NinJect. NinJect is a technology which allows dependency injection. In other words it allows the application to choose which concrete implementation of a component to create at run time.
Dependency Injection and NinJect is a large topic so I won’t try to go into it in any level of detail here but essentially I created a NinJect configuration class which tells my application that if it comes across an object of type IWebTemplateUow, then create an instance of WebTemplateUow.
The Ninject Configuration Class