I was working on a method for making controllers, as well as their categories and actions, discoverable, and noticed a few Descriptor types. On the surface, they appear to provide a few methods and properties that make it much simpler to query information about Controllers and Actions than using Reflection alone. Obtaining filters, attributes, and even lists of actions from a controller, or lists of parameters from an action, can be made with a simple method call, rather than the possible many lines of using confusing Reflection methods. However, this isn't exactly the case; the Descriptor types are abstract, their functionality lies in the corresponding Reflected*Descriptor types. This means it could be possible to describe Actions and Controllers using methods other than reflection.
This may be confusing at first; most cases controllers are created by deriving from the Controller base class, which uses reflection to obtain a method to invoke based on the Action and parameters given, as well to process filters present on both the method and class itself. However, the MVC framework never uses Controller itself, only IController, which only provides on method, Execute. This method accepts the Action as well as it's parameters, and returns a result. There is no requirement for Reflection, that is only the default implementation. However, this means that a class that implements IController directly will not necessarily follow the same Action/Parameter <-> Method mapping that the Controller class does. Having abstract classes ControllerDescriptor, ActionDescriptor, and ParameterDescriptor allows a controller to be able to describe itself, no matter how it's implemented.
I plan to use these types in my discoverability framework, so that it will be portable across different controller implementations. This should better allow it to fit in with the typical "plug in" model that the ASP.NET MVC framework currently employs.