This change simplifies a bunch of code and fits more in line with the
current design of model binding.
Now, a model binder only has to do anything if it was successful.
'return' is enough to indicate failure.
This will help future generations maintain this class. Notice that the
protected methods that are going away all just call into another
extensibility point (other than the executor). If we need to we could make
that extensible in the future and then we have the same support with fewer
hooks and less complexity.
This change corrects and ordering bug between the creation of the
'context' and the diagnostic source event that occurs before a synchronous
filter's 'after' stage.
Also made some simple changes to avoid allocating Task<T> in many common
cases. Now we'll only create the Task<T> when we really need it (async
filters).
This change just rearranges some code in the argument binder with a mind
towards performance and clarity. We're removing a few Task<T>'s here as
well in certain cases, but not yet all of them. We additionally save a
dictionary in the case where you have bound properties.
Hopefully these changes break the code into more discrete and sensible
units without multiple levels of indirection without abstraction.
- Main 'driver' code
- BindModel
- ActivateProperty
We want this change to avoid MVC eagerly reading the form. This is good
for general perf and also for scenarios where you want read the body
yourself (large file uploads).
We DO have scenarios where you want to configure the value providers
per-request or also to change the limits on the value providers (form) so
it's worth keeping these around on the context.
When the service receives a model (say, via a POST message) MVC validates it to ensure the model is in a correct state. Validation currently incurs in many allocations that can be avoided. This tackles two of them:
1. We're now caching the generic `GetEnumerator<T>` method infos generated on the fly during collection validation, and
2. We're now only initializing `ModelErrorCollection` on demand.
The first one incurs in the additional allocation of 1 long-lived dictionary object, which will grow only to the amount of `Collection<T>` types used by the model being validated. This is expected to be a small to medium number.
The second change assumes that class `ModelStateEntry` isn't thread safe, as model validation isn't multithreaded.
This resolves#4434 and #4435.
- #4339: remove non-recommended JSON formatter constructors
- affects `JsonInputFormatter`, `JsonOutputFormatter`, `JsonPatchInputFormatter`
- `JsonOutputFormatter` cleanup also impacts `JsonHelper`
- rename and make `SerializerSettingsProvider` class public; use it as appropriate
- #4409: make `SerializerSetings` properties get-only and `protected`
- affects `JsonInputFormatter`, `JsonOutputFormatter`
Recommended patterns:
- change `JsonSerializerSettings` values in `MvcJsonOptions` for almost all customizations
- find `JsonOutputFormatter` in `MvcOptions.OutputFormatters` when limiting per-result formatters
- start with `JsonSerializerSettingsProvider.CreateSerializerSettings()` when customizing a per-result formatter
- #4116
- generalize rules for `ModelMetadata` creation; minimize metadata changes when Model is updated
- down to a single special case in VDD for `Nullable<T>`
- note existing functional tests did not need to change
- remove `ViewDataDictionary(ViewDataDictionary, object)` constructor; use `new VDD<object>(source, model)`
- allow all `Model` assignments in a view component
- copy-constructed VDD in `ViewComponentContext` previously preserved the source's declared type
nits:
- do not call `virtual SetModel()` method from constructor; now mostly redundant
- logic in copy constructor and `SetModel()` is consistent but different enough to keep code separate
- add some missing doc comments
- fix doc comment property versus type confusion; never need to specify `ViewDataDictionary.` prefix
- fix a few `TemplateBuilder` comments and remove unnecessary `model: null` argument to VDD constructor
Believe it or not, this one in ActionResult is showing in TechEmpower. I
did a pass on all of the product code since the cache task actually
improves the readability of the code 😎