Extensions specify dependency contracts

[smudge202]

This possibly relates/resolves #44.

When adding a service extension, more complex services will likely depend on other services. Similarly, if an application extension author can decide not to add default implementations of services on which it depends.

In both cases, it would be useful for the extension author(s) to be able to provide user friendly messages explaining to the host author which services need to be added. In order to do this, I propose that we provide a contract API which would work in the following way (potentially / as an example):

Application Extension

public static void UseMyApplication(this Executable app)
{
  app.Requires<IDependency1>();
  app.Requires<IDependency2>("friendly name");
  // ... OnExecute code
}

Service Extension

public static void AddMyService(this IServiceCollection services, IConfiguration config = null)
{
  services.AddTransient<IMyService, ServiceImplementation>()
    .Requires<IDependency>();
  // min this example, Compose would realise IDependency is required by ServiceImplementation
  // not by IMyService (which could have the implementation overriden by the Host/App)
}

If the Host does not provide a service in which the application has specified a requirement, even though an exception would have been thrown by the underlying IServiceProvider when attempting to build up the application, instead Compose will validate the composition beforehand and throw a more user friendly exception stating that the given service is required by x.

Thoughts?

[ghost]

I think it's far more preferable to have a composition exception up front rather than leaving it to the provider. How would this work during a transition, eg: switching out IMyService at runtime

[herecydev]

I like this idea, often I would dump some implementations into a contoso.azure project and just assume that the host can use them if they wish or provide their own. It would be nice to throw a friendly error message that maybe points them to that package/project.

[smudge202]

Although Compose can Transition a service, until project funion gets going, the transitional behaviour supported out the box is very simple. The actual behaviour surrounding transitions may need more of a look at because the current implementation make's it very confusing at times...

Given I have two persistence providers which I want to transition between:

// in host
services => services.AddDocumentDbService().AddSqlServerService();
// the application will load with the SqlServerService; it was defined last and therefore overrides
// the DocumentDb service;

app.Transition<IProvider, DocDbProvider>();
// this performs a self-bind because the IProvider implementation originally
// bound when adding the document DB service was overriden

Due to how this works currently, specifying contracts on transitions would be very difficult/impossible. We need to revisit the transition api/behaviour, which can in-turn incorporate any contract behaviour we want.