# 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
Tuesday, July 02, 2013 4:51:19 AM (Central Daylight Time, UTC-05:00)
I wanted to separate out the controllers (as described in this article http://msdn.microsoft.com/en-us/magazine/jj190803.aspx) too.

Web project contains views and view models. My Controller project is a library type project and my web project is a MVC type. Web project refer to a Controller project.

How can I pass view model in controller if Controller project doesn't refer to Web project?
I can't add reference Web project in Controller project because of circular dependency.
If I delete controller project reference in Web project (MVC type) is doesn't work (404 error).
mnsasha
Tuesday, July 02, 2013 8:30:32 AM (Central Daylight Time, UTC-05:00)
I wanted to ask, how can I pass view model in view in some action method in controller class.
mnsasha
Monday, August 19, 2013 2:43:44 PM (Central Daylight Time, UTC-05:00)
A valid use case is if you have many separate teams on different projects but have a requirement for common practices, especially regarding membership.

In one of my clients their architecture isn't set up where we can use WIF or other approaches for auth. So we have published an assembly to their internal Nuget that has in it the WebAPI Controller for Membership/Role provider calls. These controllers have all the data access, crypto, etc black boxed from the users. Another Nuget package is the client Membership/Role provider which just requires the base WebAPI host url to perform all necessary functionality.
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