# Monday, April 23, 2012

Having been a part of many large enterprise ASP.NET MVC application implementations using test driven development I learned early on that separating your controller classes into a their own project significantly reduces the noise in your web project.  It wasn’t until a recent talk I gave to user group in my region that I realized that this isn’t a widely adopted practice.  For large applications with a lot of developers and a complex architecture I highly recommend it. 

Putting your controllers in a separate assembly is very straight forward.  First create a controllers project in your solution and then you just need to update your route registrations to tell them where to look for the controllers.

  1. routes.MapRoute(name: "Default", url: "{controller}/{action}/{id}",
  2.                 namespaces: new[] {"[Namespace of the Project that contains your controllers]"},
  3.                 defaults: new {controller = "Home", action = "Index", id = UrlParameter.Optional});

In order to tell ASP.NET MVC where to look for your controllers when registering your routes you use the ‘namespaces’ parameter of the MapRoute method as illustrated above.

I know that the concept of putting controllers in a separate assembly is a bit controversial and everyone seems to have a strong opinion either for or against, so let me know what side of the fence you fall on.

Saturday, June 30, 2012 3:22:21 PM (Central Daylight Time, UTC-05:00)
Keith,

How would you implement the routes.MapHttpRoute for WebAPI Controllers in a separate project? There is no namespace property.
Larry
Sunday, July 01, 2012 1:45:27 PM (Central Daylight Time, UTC-05:00)
Larry,
First off, thanks for reading.
In order to answer your question I would really need to know your architecture and what you are trying to accomplish, but I am going to cover what I think are the two possible scenarios:

1. You are trying to serve both WebAPI and standard MVC controllers through the same project.

If this is the case I would have to ask why? If you are using WebAPI as the service behind your standard ASP.NET MVC controllers then I would suggest moving the WebAPI pieces out in to there own project. If you are intent is to serve up both WebAPI and ASP.NET MVC *content* from the same project I would again have to ask why and suggest moving splitting it up in to two projects.

2. You are using a WebAPI project and attempting to move the controllers to a separate project.

This is not necessary. WebAPI is different beast all together from ASP.NET MVC and the separation of WebAPI controllers into a separate project is not necessary.

Hope this helps. If not, let me know exactly what you are trying to accomplish.
Sunday, October 14, 2012 8:55:23 PM (Central Daylight Time, UTC-05:00)
Hello Keith.
I saw your article, had the same question as Larry, and wanted to see if I could get a little clarification.

I'm working on a large ASP.NET MVC project and wanted to separate out the controllers into their own project (as described in this article http://msdn.microsoft.com/en-us/magazine/jj190803.aspx). The difference is that I'm needing/using both ASP.NET MVC 4 and ASP.NET Web API. I'm wanting a separate controllers project for "maximum" testability.

In my solution, I have two separate projects - one ASP.NET MVC 4 for serving up HTML/CSS/JavaScript (note I'm not using any standard MVC controllers, this project is all client side code that makes jQuery/Ajax calls to the Web API) and one ASP.NET Web API project (this project is only the ApiController(s), no views, HTML, etc.). I'm still wanting the Web API project to be hosted in IIS, not self-hosted.

Anyway, I'm having trouble getting this solution working. How can I break out my Web API controllers into their own separate project and use them from my HTML/JavaScript code in my separate MVC project?

Thanks.
Brooks
Monday, February 04, 2013 3:34:16 PM (Central Standard Time, UTC-06:00)
Why is a good idea to remove the controllers from the web application? It seems to be like its just extra work IMO. It seems like its a style issue rather than a best practice. Can explain why its important?
Justin England
Monday, March 04, 2013 3:27:54 PM (Central Standard Time, UTC-06:00)
I think separating certain controllers and keeping them in their own project or assembly can be a very good idea. For example, if in each project you rely on the same security logic, that is, you have the same Log in, Log out, User/Roles Administration, then separating this security layer into a different project is a good idea. I kept writing the same controllers over and over again and again, and finally got fed up with it. Now I am working on pure security project which I plan to reuse in other projects.
Husein
Monday, May 13, 2013 5:07:54 AM (Central Daylight Time, UTC-05:00)
Ok. I just have to say that this is not 100% straight forward. I created a solution, add a new blank project and moved my controllers over and made changes to the route config and got errors. Would be nice if you could elaborate on this a bit. Do I need to reference system.web.mvc in my controllers project?? There is OBVIOUSLY other thing(s) which need to be done.
Jon
Name
E-mail
(will show your gravatar icon)
Home page

Comment (Some html is allowed: a@href@title, strike) where the @ means "attribute." For example, you can use <a href="" title=""> or <blockquote cite="Scott">.  

Enter the code shown (prevents robots):

Live Comment Preview