MVC Routes... How do I set up my controller to deal with /configuration/building/add

Question

I have an architecture where I have numerous objects I can configure. Examples of URLs I want are as follows:

/configuration/building/add
/configuration/building/edit/1
/configuration/group/add
/configuration/group/edit/1

I have a Configuration controller but how do I intercept or deal with building/add and building/edit/1 etc... If it were AddBuilding I could simply add an AddBuilding() function, and similarily how do I get it to work for configuration/building/edit/

Answer 1

Here's what you can do for the first one - open up the Global.asax.cs file of your site and put this in RegisterRoutes before the standard MVC catch-all route (the one that uses the route "{controller}/{action}/{id}"):

routes.MapRoute("AddBuilding", "configuration/building/add",
  new { controller = "Configuration", action = "AddBuilding" });

The others will be the same, but different names (first parameter) and action, whislt the edit routes but would include an {id} route placeholder and route parameter (but not optional - unlike the MVC default route):

routes.MapRoute("EditBuilding", "configuration/building/edit/{id}",
  new { controller = "Configuration", action = "EditBuilding" });

By leaving the id off the route defaults we make it required. I'm assuming this, because I'm guessing the Url /Building/Edit doesn't logically map to anything.

As a side node - including verbs in your urls isn't really in keeping with REST methodology, however you're not the first to do it by a long way (I include myself in that too). That said - trying to keep to it usually makes your life a lot easier, as you'll find your controllers will be cleaner, as will your route table, and your site's URL space will be a lot smaller and more obviously hierarchical. This last point is - handy for zooming around the site at dev time, but more importantly it's crucial for SEO.

So (I've commented this code heavily, hopefully enough to provide some nuggets of knowledge!):

public class ConfigurationController{

  ////HTTP GET /Buildings
  /// DISPLAYS BUILDINGS
  public ActionResult Buildings(){
    //get model and return view that shows all buildings with perhaps a 
    //partial in that for creating a new one (or you can use another action)
    //The HTML form on that view will POST to the URL handled by the method below.
  }

  ////HTTP POST /Buildings
  /// CREATES A NEW BUILDING
  //use ActionName here to make this and the method above accessible through
  //the same URL
  [ActionName("Buildings")]
  [HttpPost]
  public ActionResult CreateBuilding(BuildingModel model){
    //validate the model, create the object and return the same
    //view as the Buildings() method above (after re-loading all the
    //buildings.  Or, you can issue a redirect, effectively transferring
    //control back to the method above.
  }

  ////HTTP GET /Configuration/Building/id
  ///DISPLAYS A BUILDING
  public ActionResult Building(int id){
    //get building and return view, which also contains Edit functionality
  }

  ////HTTP POST /Configuration/Building/id
  ///EDITS A BUILDING
  [HttpPost]
  public ActionResult Building(int id, BuildingModel model){
    //very similar to the CreateBuilding method - and again you might
    //either simply return a building view at the end, or redirect
    //to the method above.

    //Note that we don't need [ActionName] here because this and the
    //get method can have the same method names, because they are overloads
    //i.e. since they have different method signatures we can call them the same
    //thing in code.
  }
}

I've left off the group stuff to keep it short, and hopefully you'll be able to see how to do it from there.

With this in place, we only need at most two routes in Global.asax.cs - although I think the order will be important:

//handles both GET and POST to this URL, i.e. our view & edit operations
routes.MapRoute("IndividualBuilding", "/configuration/buildings/{id}", 
  new { controller = "Configuration", action = "Building" });
routes.MapRoute("Buildings", "/configuration/buildings",
  new { controller = "Configuration", action = "Buildings" });

Now we are using the HTTP verbs to signify what we intend to do with a particular request, and our URLs have become more 'logical'.

Another refactor

If you want to be 'clever' you can lump both buildings and groups under two routes

//handles both GET and POST to this URL, i.e. our view & edit operations
routes.MapRoute("Individual", "/configuration/{controller}/{id}", 
  new { controller = "Configuration", action = "List" });
//again, handles GET and POST
routes.MapRoute("Collection", "/configuration/{controller}",
  new { controller = "Configuration", action = "Single" });

Now you do both buildings and groups controllers as I showed above, but replace Buildings (remembering the ActionName attribute on the second method) with List and Building with Single.

One final thing to consider is that because of the default MVC route:

routes.MapRoute("Default", "{controller}/{action}/{id}", 
  new { controller = "Default", action="Home", id = UrlParameter.Optional });

Both of your two controllers can still be routed via /Buildings/Single/1 or /Groups for example. This is a minor issue (dupe content isn't great SEO) but it can be something that people can use to sniff your site.

If you absolutely want to prevent this other url format; you can take out the default route, meaning you'd have to explicitly route other stuff that might already work (not a great issue).

Or you can use a little trick that will make it far harder: use explicit [ActionName] attributes with characters in the route name that won't be allowed through IIS - e.g. ":Single" or ":List", and then adjust our two routes from a couple of code blocks back accordingly.