- A GatewayAgent layer into our controller – the GatewayAgent layer separates the concerns of the controller from the concerns of our WCF SOA layer.
- An AutoMapper implimentation into our GatewayAgent – the mapper will map our presentation entities to our Domain entities.
- Our presentation entity validation classes into our presentation entities – as we are using Fluent validation, we may want to ditch this later and inject a different type of validation.
The following diagram show part of the web site’s global.asax file. This code uses Ninject to inject the above 3 items.
|The Ninject Binding in the Global.asax class|
Obviously, the web site has a reference to the Ninject.dll.
Most of this is set in stone for our site but one thing to note. As more development is done we will need to add more validators as we add more presentation entities to our site. So when we add an Invoice presentation entity to the site a related Invoice Validator class will need to be added to the ConfigureKernel method, shown above, in our global.asax file.
Note: the line:
means, when we call validate on a Contact presentation entity,
we would like to use the ContactValidator class to carry out the validation
|Sample Contact Validator|
You can see in the ConfigureKernel method above that we also inject a ContactGateway.
The following line shows this:
This means that when we refer to IContactGateway we would like to use the concrete class ContactGateway.
So in our controller we see the following code:
Why is this good? Because you can then mock up a ContactGateway in a unit test to test your controller.
|A unit test for the controller|
This is the end of Part 1 – Explanation of Ninject Bindings and where we used them in our MVC Website
I will do another couple of posts on the other layers mentioned in the architecture diagram at the start of this post.