IActionConstraint follows a provider model similar to filters. The
attributes that go on actions/controllers can be simple metadata markers,
the 'real' constraint is provided by a set of configurable providers. In
general the simplest thing to do is to be both an
IActionConstraintMetadata and IActionConstraint, and then the default
provider will take care of you.
IActionConstraint now has stages based on the Order property. Each group
of constraints with the same Order will run together on the set of
actions. This process is repeated for each value of Order until we run out
of actions or run out of constraints.
The IActionConstraint interface is beefier than the equivalent in legacy
MVC. This is to support cooperative coding between sets of constraints
that know about each other. See the changes in the sample, which implement
webapi-style overloading.
This change removes WebAPI-style method parameter overloading and the
automatic mapping of 'unnamed' actions based on method names. For all
practicaly purposes, this change restores the MVC5 behavior for action
selection.
WebAPI-style overloading will be brought back in the future via a set of
opt-in constructs.
This adds support for attributes which interact with reflected model.
These conventions are applied after all of our built-in constructs so that
you can see and modify the results.
This change exludes internal and nested types from being treated as
controllers. This is consistent with MVC5's behavior.
DefaultActionSelectionConventions was primarily tested through running
action selection. I wanted to also test the methods with substantial logic
in this class, so I moved a spate of a classes from private classes inside of the
integration tests to public classes so they could be shared. I also added
tests to fill gaps in DefaultActionSelectionConventions, which is the vast
vast majority of this change.
YishaiGalatzer
sornaks
Ryan Nowak
David Fowler
Ben Brown