When dealing with the sharing of code on a project, I feel like having conventions and standards and following are of the utmost importance. Only by following the patterns can someone else walk in and understand what is going on. It also helps newer programmers by letting their acquired knowledge apply across environments.
Occasionally I see people really get into routing when dealing with a web MVC framework. I have even seen some who place custom routing in their top 5 must haves when looking for a web MVC framework. While it can be fun and rewarding, the most elegant solution sometimes is the one that is default. Further in my environment we hold to the standard that the simplest is usually the best. This means using default routing if possible, period. The first choice we made was already MVC .NET and therefore adhearing to the internal conventions is implied. For the sake of this conversation we will be assuming we are using MVC as a UI. API functionality beyond REST may or may not require a different approach. Let us take a walk down the path of :
‘What does that mean practically?’
Here is the default route registered in a new project:
Imagine you publish to a place that is reachable via http://example.com/. Say you have a controller called MyController that resides within the Controllers folder in your project. It has two methods : Index() and World(). If you go to http://example.com/My you will see the output of the Index() action on MyController since the default action is Index(). You can also execute the same action by going to http://example.com/My/Index. Hopefully this aids in making sense of the fact that if you visit http://example.com/My/World the action MyController.World() is executed. Also, by understanding how defaults work, you understand that when you visit http://example.com/ the routing is wanting you to have a controller named Home with an action method of Index().
This brings us to the first point of contention I will acknowledge. That of the third parameter ‘id’. If we were going to leave the default routing and simply use this value, we end up having method parameters named id when they may be used as something like ‘name’. Here is where my team and I have made the call that if it is any sort of identifier (like name or GUID, which it usually is) that we leave the default routing and reassign the value to a more specific variable inside the method.
Note that this routing pattern is matching the URL and not any parameter values like those sent in a HttpPost. For example the Login() method of the default AccountController takes a LoginModel and a returnUrl without changing the default route. The LoginModel is set via POST values and often the returnUrl is added to the URL queryString like http://exmaple.com/Account/?returnUrl=some_value_here. On my team these are the preferred methods of assigning values when building with .NET MVC.
Does this mean we never add routs. The short answer is: We never add routs. We may make exceptions in extreme situations, but we have not come across any that need it. This quickly brings us to Areas. Yes we use the defaults here too.
Creating an Area by the name of AreaName you are given the routing:
So in this case if you had a controller named MyController like mentioned above but in the project folder Areas\AreaName\Controllers you could get to the World() action method by visiting http://example.com/AreaName/My/World. Because we often build our controllers for areas in external libraries we add a little salt to our area routs. *Gasp* However, we still don’t actually modify the default route.
As you can see above, we add the namespace for the area and a default controller. This is still the only routing we need.
You still may be asking yourself, where does this rule stop? The answer is simple: When making things work with the default routs is more complicated than route clutter. I have yet to see where this is the case and it doesn’t warrant a whole new project. Keeping it simple is an art.