This is the first step is some more refactorings to come in the future
with the goal of making MVC less monolythic. This makes the core of MVC
more reusable and more in line with the design of other vNext platform
components.
With this change, Mvc.Core contains just the minimal guts needed to build
a working app.
- Action Discovery
- Action Invoker
- Filters
- ObjectResult
- Model Metadata
- Model Binding
- Formatters
- Validation System
And yes, we are aware of the irony of 'minimal MVC' not including the view
system. The idea is that this is the kernel of an MVC app, and anything
real is layered on top.
The most noticable impact of this change is that MvcOptions has been blown
apart into more managable chunks. See the various ConfigureMvc*** methods.
The new Mvc.Extensions package is a placeholder while we evaluate and tune
the new definitions. Expect more changes as features are move to their own
packages, and in some case their own repositories.
For now there is no experience to bootstrap an Mvc.Core app. That's coming
next.
Combining IControllerModelBuilder and IActionModelBuilder into a pipeline
of IApplicationModelBuilders. Extensibility for framework features (Auth,
Cors, etc) should implement an IApplicationModelBuilder to add data to
models before IApplicationModelConventions have a chance to run.
Also deleting IGlobalFilterProvider while touching this code, this should
have been removed a while ago when we removed other options facades.
The change here is to make an attribute route defined on a base class
inherited only if no other routes were defined 'closer' to the controller
class.
To put another way, attribute routes can either be inherited or
overridden, you can't inherit + add your own.
services
* Added WithControllersFromServiceProvider that replaces the default
controller activator with a service based one.
* Move activation to DefaultControllerFactory
* Modify [Activate] behavior so that it no longer activates services. Use
[FromService] attribute to hydrate services
Fixes#1707
This change allows you to set global defaults for ApiExplorer on the
ApplicationModel. Additionally, we're more lenient about configuring
ApiExplorer = on with conventional routing. If you turn on ApiExplorer at
the application level, we'll just skip over all conventionally routed
controllers instead of throwing.
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.
This change adds an interface for the functionality provide by
RouteConstraintAttribute, and adds support for configuration constraints
on actions/action-model.
- #EngineeringDay
- VS does not yet format auto-properties nicely; reverted what it did
Also revert changes under
- test/Microsoft.AspNet.Mvc.Razor.Host.Test/TestFiles
- #EngineeringDay
- Total replaced: 660 Matching files: 270 in *.cs
- Total replaced: 250 Matching files: 32 in all other files
- Total replaced: 22 Matching files: 8 in a few stragglers
Did not change files under following directories
- test\Microsoft.AspNet.Mvc.Razor.Host.Test\TestFiles\Output
- test\Microsoft.AspNet.Mvc.FunctionalTests\compiler\resources
- test\WebSites\TagHelpersWebSite
(Razor generates trailing whitespace in a case or two)
This change enables some compatibility scenarios with MVC 5 by expanding
the set of legal ways to configure attribute routing. Most promiently, the
following example is now legal:
[HttpPost]
[Route("Products")]
public void MyAction() { }
This will define a single action that accepts POST on route "Products".
See the comments in #1194 for a more detailed description of what changed
with more examples.
This also comes with a rename of the namespace
Microsoft.AspNet.Mvc.ApplicationModel to
Microsoft.AspNet.Mvc.ApplicationModels.
Also tuned up some parameter and variable names for increased
understandability.
Ryan Nowak
N. Taylor Mullen
Kirthi Krishnamraju
Kiran Challa
Harsh Gupta
Yishai Galatzer
Hao Kung
Pranav K
sornaks
SonjaKhan
Doug Bunting
ianhong