ApplicationPart should be a feature collection

[davidfowl]

Today ApplicationPart need to implement interfaces in order for the feature provider to interact with the part. This means that parts cannot be extended without making a new derived one. Instead, ApplicationPart should be a feature collection so that new interfaces can be added/removed from existing parts.

It will allow people to extend AssemblyPart for example without making a new derived type.

/cc @javiercn @rynowak @Eilon @pranavkm

[rynowak]

I like this, but is this something we'd do in 1.0.1? This seems breaking changey

[davidfowl]

Yea, we can talk about it some more after 1.0.0

[rynowak]

I can actually think of a way we can do this without breaking changes. Add the feature collection, and then have a default implementation on ApplicationPart (which is an ABC) that does a cast to the existing feature interfaces.

[pranavkm]

How does the user apply a feature to all parts - ones already in the part manager and ones that are added later? e.g.

foreach (var part in partManager.Parts.OfType<AssemblyPart>())
{
   part.Features.Set<ITestFeature>(foo);
}

partManager.Parts.Add(new AssemblyPart(..)); <-- How do I ensure this part also has the feature?

[javiercn]

@pranavkm the order in which you call things during startup is important. You add parts first then you create features.

[pranavkm]

Sure, but it makes it much harder to compose it. For instance, we wouldn't be able to light up the the ICanHazViewsFeature on AssemblyPart as part of registering Razor the way we register FeatureProviders today. (https://github.com/aspnet/Mvc/blob/dev/src/Microsoft.AspNetCore.Mvc.Razor/DependencyInjection/MvcRazorMvcCoreBuilderExtensions.cs#L64 bit).

[javiercn]

@pranavkm let's talk offline

[pranavkm]

Discussed this offline and here's what we have:

We decided the current model of creating parts doesn't lend itself to a feature collection model. The guidance would be

1. Use broad interfaces like IApplicationPartTypeProvider, ICompilationReferencesProvider. We should add additional interfaces like IResourcesProvider etc to make feature light up such as embedded views.
2. Use an IFeatureProvider that downcasts when these interfaces aren’t sufficient. For instance, precompiled view discovery would work this way. We’ll remove IViewsProvider and associated types from Mvc.Core.

[pranavkm]

We don't have any immediate work scheduled for this. Closing this for now and we can track the embedded view work via #5144.