Separates the MMP into two phases:
1). Creation of the ModelMetadata, discovery of properties and attributes
(reflection) is part of the MMP
2). Lookup of details based on attributes is now part of another phase,
and has its results cached.
Users can now implements and register an IFooMetadataProvider to customize
a single aspect of metadata (see how data annotations does it).
This is a major refactor of how IBinderMetadata interacts with model
binders and value providers. We're doing this to support better
extensibility for metadata in ApiExplorer.
You'll notice a bunch of deleted code in DefaultApiDescriptionProvider
that maps metadata marker interfaces to a fixed list of Api sources. This
is replaced now with IBindingSourceMetadata - which also replaces the
hierarchy of marker interfaces. Now user code can create an arbitrary
binding source and have a consistent API for model-binders,
value-providers and full-visibility in ApiExplorer as
well.
Additonally, there's some error checking in place that better enforces the
constraints we already have in the system. IE you can't create a 'greedy'
model binder that uses value-provider data.
Two additional enhancements are planned for followup PRs:
1. Add a BindingSource property to model-metadata. This will remove some
duplication, but I want to delay it because it would touch another 10 or
so files.
2. Add an extensibility interface for our 'special' model binders like the
file binder so these can show up in ApiExplorer as well.
This change makes ApiDescription and ApiParameterDescription aware of all
of the new features we built into model binding for enhanced DTO support
(uber-binding).
The main change is that instead of sticking just to the declared
parameters on the action itself, we now traverse model metadata and break
the parameters down based on their logical data source.
This means that a model like the below will yield 3 parameters:
public class ProductChangeCommandDTO
{
public int Id { get; set; }
[FromBody]
public ProductDetails Changes { get; set; }
[FromQuery]
public string AdminComments { get; set; }
[FromServices]
public IProductRepository Repository { get; set; }
}
The 'Repository' will be hidden, as it's not related to user input.
Additionally, we treat different sources differently. In the
above example, 'Changes' is from the body and will be treated as a
leaf-node.
However if you use nested DTOs that are bound from the query string (using
[FromQuery]) or similar, we'll recursively explore to find as much
structure as possible.
This information is combined with data from the route template to give a
much more complete picture than we ever could in the past for parameters,
especially when DTO/Command pattern is used.
The ParameterModel and ParameterDescriptor have had a notion of
optionality for a while now, even though all parameters are treated as
'optional' in MVC.
This change removes these settings. Optionality for overloading in webapi
compat shim is reimplemented via a new binder metadata.
1) Expose the simplified relative path template by cleaning up constraints, optional and catch all tokens from the template.
2) Expose the parameters on the route template as API parameters.
3) Combine parameters from the route and the action descriptor when the parameter doesn't come from the body. #886 will refine this.
4) Expose optionality and constraints for path parameters. Open question: Should we explicitly expose IsCatchAll?
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.
Harsh Gupta
Ryan Nowak
Yishai Galatzer
Chris Ross
jacalvar
sornaks