These are *new style* for configuring MVC in services. We're adding these to make
things feel a bit more tailored to those particular scenarios.
----
The main reason for this is that we've had repeated community asks for an
*API-optimized* way of configuring MVC. I don't think that using AddMvcCore
is a suitable building block, because it has too many options that you want.
I've think I've identified the reasonable set of features that should be part
of the default experience for APIs. All of these things are already pay-for-play
and are activated by the presence of attributes. The only additional cost is
loading of assemblies and a few additional inspections of the attributes
(cached).
----
Additionally the AddControllers experience is composible. You can add views
to it, or add pages and get the whole thing.
AddRazorPages is basically an alias for what AddMvc does today. We don't
currently have a way to add pages without controllers (the opposite is true).
Based on feedback we could specialize this more.
----
Branding and perception are important, and we've users ask for more flexibility
in what gets added. The plan is to update the templates to use this experience
in preview4, and see what kind of feedback we get.
* Make endpoint middleware explicit
This change makes the endpoint middleware explicit again, and updates
all of the templates.
The other change here is make UseEndpoints be the place where you
register endpoints. This is vital because it puts your code visually at
the point of the pipeline where it executes.
Lastly, I removed support for UseMvc with endpoint routing. This is
causing issues for some security features, and we're moving in the
direction of trying to make the middleware heavy implementation required
in 3.0. There are some issues we won't be able to fix in MVC if we can't
unambiguously know if UseMvc was used or the middleware.
* Relayer MvcEndpointDataSource
Separates the statefulness of the data source from the business logic of
how endpoints are created.
I'm separating these concerns because one of the next steps will split
the MvcEndpointDataSource into two data sources.
* Simplify MvcEndpointInfo
Removing things that are unused and leftovers from the 2.2 design of
this feature.
* Remove per-route conventions
Removes the ability to target endpoint conventions
per-conventional-route. This was a neat idea but we have no plans to
ship it for now.
Simplified MvcEndpointInfo and renamed it to reflect its new purpose.
* Remove filtering from MvcEndpointDataSource
This was neat-o but we're not going to ship it like this. We're going to
implement filtering in another place. Putting this in the data source is
pretty clumsy and doesn't work with features like application parts that
need to be baked in addservices
* Simplify ActionEndpointFactory
* Split up data sources
* Use UseRouting in functional tests
I've rejiggered our functional tests to de-emphasize UseMvc(...) and
only use it when we're specifically testing the old scenarios.
UseMvc(...) won't appear in templates in 3.0 so it's legacy.
* Update templates
* Add minor PR feedback
* one more
Artak
Artak Mkrtchyan
Ryan Nowak
Chris Ross
Nate McMaster