This post is going to tell you exactly how to use the same in DI container in your MVC Controllers and your Web Api controllers, so you can share the same set of services. Of course after you have seen this, it will be immediately clear how to use different containers in both, if you like to do so. The example will be implemented using the Repository pattern, AutoFac, Entity Framework 5 and the EF powertools.
Setting things up
Fire up Visual Studio 2012 RC and start a new MVC 4 empty project:
Call it anything you like. After Visual Studio is done creating your project layout, we’re going to implement the Repository pattern. In a production application you’ll probably want to split your solution into multiple projects, but for now we’re going to do everything in one. First, make sure you have installed the Entity Framework powertools using the Visual Studio extension manager:
After this, use NuGet to add EF 5.0 support to your MVC project:
If you don’t see the PreRelease version, make sure to set the combobox in the top of the screen to “Include Prerelease”. There is one last thing left to do to complete the setup and that’s adding a DI container to our project. You can of course use anything you like, but I’m going with AutoFac. If you want to find out why you should use AutoFac too you can read this. In short, AutoFac combines a full feature set with great performance, is easy to configure and has great support. You can use NuGet to add AutoFac to your project:
Make sure you get the “MVC 4 RC Integration” package. This will provide you with easy integration and will also install the basic AutoFac DLL’s. That’s it, now we’ve got everything we need (assuming you already have a database).
Creating the repository
Create the following interface:
01 using System;
02 using System.Collections.Generic;
03 using System.Linq;
04 using System.Text;
05 using System.Threading.Tasks;
06
07 namespace Adventureworks.DAL.Repository
08 {
09 public interface IRepository<in TKey,TEntity> {
10 void Add(TEntity entity);
11 void Delete(TEntity entity);
12 void Update(TEntity entity);
13 IEnumerable<TEntity> GetAll();
14 TEntity GetById(TKey id);
15 }
16 }
Now let’s implement it using EF 5.0 and the powertools. I really like the Code only feature of the new Entity Framework release, totally removing the .edmx file. But until recently you couldn’t reverse engineer code only from an existing database. Luckily the EF powertools fix this for us. Right click your Web Project and go the “Entity Framework” menu and select “Reverse engineer Code first”:
Select the database of your choosing and let the tooling do it’s magical stuff. After all is said and done, you will have Entity classes, a DBContext and a file containing the code for configuring the DbContext. Create a class which implements the IRepository interface like this:
1 using System;
2 using System.Collections.Generic;
3 using System.Data.Entity.Infrastructure;
4 using System.Linq;
5 using System.Text;
6 using System.Threading.Tasks;
7 using Adventureworks.Domain;
8
9 namespace Adventureworks.DAL.Repository.EntityFramework
10 {
11 public class EntityFrameworkProductRepository : IRepository<int,Product>
12 {
13
14 public void Add(Product entity)
15 {
16 PerformAction((context) =>
17 {
18 context.Product.Add(entity);
19 context.SaveChanges();
20 });
21
22 }
23
24 public void Delete(Product entity)
25 {
26 PerformAction((context) =>
27 {
28 context.Product.Attach(entity);
29 context.Product.Remove(entity);
30 context.SaveChanges();
31 });
32 }
33
34 public void Update(Product entity)
35 {
36 PerformAction((context) =>
37 {
38 context.Product.Attach(entity);
39 context.Entry(entity).State = System.Data.EntityState.Modified;
40 context.SaveChanges();
41 });
42 }
43
44 public IEnumerable<Product> GetAll()
45 {
46 return Read((context) =>
47 {
48 return context.Product.AsNoTracking().ToArray();
49 });
50
51 }
52
53 public Product GetById(int id)
54 {
55 return Read((context) =>
56 {
57 Product p = context.Product.AsNoTracking().SingleOrDefault((pr) => pr.ProductID ==
id);
58 if (p == null)
59 {
60 throw new ArgumentException("Invalid id: " + id);
61 }
62 return p;
63 });
64 }
65
66 private void PerformAction(Action<AdventureWorks2012Entities> toPerform)
67 {
68 using (AdventureWorks2012Entities ents = new AdventureWorks2012Entities())
69 {
70 ConfigureDbContext(ents);
71 toPerform(ents);
72 }
73 }
74
75 private T Read<T>(Func<AdventureWorks2012Entities, T> toPerform)
76 {
77 using (AdventureWorks2012Entities ents = new AdventureWorks2012Entities())
78 {
79 ConfigureDbContext(ents);
80 return toPerform(ents);
81 }
82 }
83
84 private void ConfigureDbContext(AdventureWorks2012Entities ents)
85 {
86 ents.Configuration.AutoDetectChangesEnabled = false;
87 ents.Configuration.LazyLoadingEnabled = false;
88 ents.Configuration.ProxyCreationEnabled = false;
89 ents.Configuration.ValidateOnSaveEnabled = true;
90
91 }
92
93 }
94 }
There are a couple of things going on here. Starting on line 66 I’ve created three helper methods which set up the DbContext correctly and dispose it. These methods are used by calling them and supplying a Lambda which uses the DbContext. Let’s take a look at the GetAll method on line 44. You can see that I don’t use change tracking. Change tracking is something you get as a bonus when using the EF, I like to abstract this away with my Repository implementation. It’s also completely useless in a web application since all state is gone after each request and it has a lot of overhead. “But how do you update if you don’t have any change tracking?” you ask?, well take a look at the Update method on line 34. Just set the whole entity as “Modified” and the EF will perform an update for you.
Creating a Web API Controller
Now let’s create a Web API controller to perform some CRUD functionality:
Implement it like this:
1 using System;
2 using System.Collections.Generic;
3 using System.Linq;
4 using System.Net;
5 using System.Net.Http;
6 using System.Web.Http;
7 using Adventureworks.DAL.Repository;
8 using Adventureworks.Domain;
9
10 namespace Adventureworks.Web.Controllers
11 {
12 public class ProductController : ApiController
13 {
14
15 private IRepository<int, Product> _productRepository;
16
17 public ProductController(IRepository<int,Product> repository)
18 {
19 _productRepository = repository;
20 }
21
22 public IEnumerable<Product> Get()
23 {
24 return _productRepository.GetAll();
25 }
26
27 public Product Get(int id)
28 {
29 try
30 {
31 return _productRepository.GetById(id);
32 }
33 catch (ArgumentException ex)
34 {
35 throw new HttpResponseException(new HttpResponseMessage(HttpStatusCode.NotFound){ Content = new StringContent(ex.Message)});
36 }
37 }
38
39 // POST api/product
40 public HttpResponseMessage Post(Product product)
41 {
42 ValidateProduct();
43 _productRepository.Add(product);
44 return new HttpResponseMessage(HttpStatusCode.Created) { Content = new StringContent(Url.Route("DefaultApi",
45 new{controller="Product",id=product.ProductID}))};
46 }
47
48 // PUT api/product/5
49 public HttpResponseMessage Put(Product product)
50 {
51 ValidateProduct();
52 _productRepository.Update(product);
53 return new HttpResponseMessage(HttpStatusCode.NoContent);
54 }
55
56 // DELETE api/product/5
57 public HttpResponseMessage Delete(Product product)
58 {
59 _productRepository.Delete(product);
60 return new HttpResponseMessage(HttpStatusCode.NoContent);
61 }
62
63 private void ValidateProduct()
64 {
65 if (!ModelState.IsValid)
66 {
67 throw new HttpResponseException(new HttpResponseMessage(HttpStatusCode.BadRequest));
68 }
69 }
70 }
71 }
Let’s go to line 65 first. This is a helper method which uses the built in Model Binding feature to validate the incoming product. This means that you can just decorate your Product class with attributes or implement IValidatable object to implement data validation. Keeping up with the spirit of rest, this method will generate a BadRequest statuscode when the incoming product is invalid. Now jump up to the constructor. The controller only works with an IRepository interface to perform the crud functionality, it never knows anything about the Entity Framework. This is the key advantage of DI, as we can now mock the repository and unittest our controller. Now jump to line 42; The Post method. A post in REST means an insert. It’s also in the spirit of REST that you use the HTTP statuscodes to signal what’s going on. When you create new content, you should provide the caller with an url to the new content. Similar to the Post method, you can see that the other methods also use statuscodes to indicate if everything went well or not.
Wiring everything up
Last thing left to do is to configure our container and integrate it with MVC. Here’s my Global.asax:
1 using System;
2 using System.Collections.Generic;
3 using System.Linq;
4 using System.Web;
5 using System.Web.Http;
6 using System.Web.Mvc;
7 using System.Web.Routing;
8 using Adventureworks.DAL.Repository.EntityFramework;
9 using Adventureworks.Web.Services;
10 using Autofac;
11 using Autofac.Integration.Mvc;
12 using Autofac.Integration.WebApi;
13
14 namespace Adventureworks.Web
15 {
16 // Note: For instructions on enabling IIS6 or IIS7 classic mode,
17 // visit http://go.microsoft.com/?LinkId=9394801
18 public class MvcApplication : System.Web.HttpApplication
19 {
20 protected void Application_Start()
21 {
22 AreaRegistration.RegisterAllAreas();
23
24 FilterConfig.RegisterGlobalFilters(GlobalFilters.Filters);
25 RouteConfig.RegisterRoutes(RouteTable.Routes);
26
27 var builder = new ContainerBuilder();
28 builder.RegisterControllers(typeof(MvcApplication).Assembly);
29 builder.RegisterApiControllers(typeof(MvcApplication).Assembly);
30 builder.RegisterType<EntityFrameworkProductRepository>().AsImplementedInterfaces().InstancePerApiRequest().InstancePerHttpRequest();
31 var container = builder.Build();
32
33 DependencyResolver.SetResolver(new AutofacDependencyResolver(container));
34 GlobalConfiguration.Configuration.DependencyResolver = new AutofacWebApiDependencyResolver(container);
35 }
36 }
37 }
First up are lines 28-32. This is the configuring of the AutoFac container. You register all the controllers for MVC and the Web API with two lines of code. This is done on lines 29 and 30. On line 31 I am registering the EntityFrameworkProductRepository in a per request scope, for MVC controllers and Web API controllers. On line 32 the container is built. On line 35 the container is registered for MVC controllers. On line 36 it’s registered for API controllers. This is what bites people the most. To use DI with MVC, you need a class which implements IDependencyResolver. To use DI with the ASP.NET Web API, you also need a class which implements IDependencyResolver. But these interfaces aren’t the same and they live in different namespaces. The dependency resolvers are also registered differently as you can see on lines 35 and 36. Luckily, AutoFac’s MVC integration package which we installed earlier, contains dependency resolvers for use to use, otherwise we had to implement these ourselves. That’s all! Now go out and test your REST service with your favorite tool.