Application IServiceCollection Intercepts

[smudge202]

One of our extensibility points is the ability to define new Application types (Compose.Owin for example). Applications can override the Execute and ExecuteAsync virtual methods of Executable, but it feels like we're missing other points of interception.

For example, I typically use TestApplications which allow me to perform setup/teardown as part of the Execution. However, I'd also like the ability to examine and modify the IServiceCollection, potentially both before and after the host has completed UseServices.

Intercepting before allows me to override services that would otherwise be TryAdded by the Host, whilst after allows me to examine and modify the collection.

Thoughts?

[herecydev]

Very nice idea, shouldn't be breaking and allows for a nice level of extensibility and control over the application :shipit:

[smudge202]

Some possible implementation details to better clarify the proposal:

// change this method
public static void UseServices(this Application app, Action<IServiceCollection> configure)
{
  var services = new ServiceCollection();
  // the following method is virtual and just blank by default
  // the intent is to allow applications to define a service so
  // that implementations using `TryAdd` are skipped
  app.PreServiceConfiguration(services);
  // add host services:
  configure(services);
  // transitional stuff
  ApplyTransitions(services);
  // Again, a blank virtual method on Application
  // this time allowing visibility of the configured services
  // and the option to make changes to the service collection
  app.PostServiceConfiguration(services);
  // Compose then essentially persists the collection
  Persist(services);
}