ASP.Net MVC ambigious action methods - why the path choosen

Question

Is there someone who could shed a light on why ambiguous methods are not allowed in ASP.Net MVC?
I updated my question just to clarify it (using Carson63000 example from his answer), the question itself remains the same.

So, lets say we have the following action

/article/list/sport

which calls

public ActionResult List(string category) { }

and want to be able to have the following action as well:

/article/list/sport/20110904

which we would like to call accompanying method

public ActionResult List(string category, DateTime date) { }

Currently the framework throws an AmbiguousMatchException since it found two methods called List. That's the only reason for throwing the exception, that more than one method with was found that matches the actions name.

After the framework has figured out what method to use and decided that it is not ambigious, it will then try to map the supplied data from the request to the parameters of the method. Why not do this the other way around? First get all applicable methods, and then try to find the best fit by mapping parameters.

If ambiguous methods where allowed, I think the following is still possible to do.
Given that /article/list/sport uses the route /{controller}/{action}/{category} and that /article/list/sport/20110903 uses the route /{controller}/{action}/{category}/{date}
it would then still be possible to map data for url /article/list/sport?date=20110903 since it will match the route for just category, but can still map the data for method public ActionResult List(string category, DateTime date) { }.

At the moment I fail to see the reason for not allowing ambiguous methods from a design perspective. The only thing I can think of myself is that it will slow down the framework too much, and therefor the current solution is the more logical one. Or am I missing another point here?

Answer 1

If I understand your question correctly, I would say it is because you generally don't have explicit control over the parameters passed to an action.

Remember that the model binding will, by default, take them from a number of different places, including ones that are outside your control, like querystring.

It sounds like you're thinking that you should be able to have something like this:

/article/list/sport

Which calls ArticleController.List(string category);

And also:

/article/list/sport/20110901

Which calls ArticleController.List(string category, DateTime date);

But what happens when someone types the URL /article/list/sport?date=20110902 ?

It just sounds like a recipe for unpredictable behaviour, and in return, what real benefit would you get from this sort of action overloading?

Answer 2

As for getting a list of applicable methods for resolving an action, I don't see any problem with that, it is quite easily doable, as it turned out. Resolving the parameters for each method is also manageable, the only problem that seems to exist is determining the best fit.

But still it should be possible to choose one method over another some way and if there would be some sort of tie, throw the AmbiguousMethodException.