Discussion: Consider using configuration options to register modules

[lloydkevin]

Consider a registration experience like this:

builder.Services.DiscoverAndRegisterModules(c => 
{
  c.SolutionName = "eShop2";
  c.AutoDiscover = false;
  c.RegisterModulesFromAssemblies(typeof(IUserService).Assembly); // blatantly _borrowed_ from MediatR
  c.RegisterModulesFromAssemblyContaining<IPaymentService>();
  c.SetConfiguration(builder.Configuration);
  c.SetLogger(myConsoleLogger);
  // .... OR

 c.AutoDiscover = true; // default
 c.RegisterModulesFromAssemblyContaining<MyDataContract>();

});

Lots of packages use this configuration style to handle setup.
If nothing is passed, it would use sensible defaults, but it gives the user to option to override certain behavior of the registration process.
While also avoiding having to keep passing in potentially more and more optional parameters as the feature set grows.

Examples of features would be:

• Allowing users to skip auto discovery (for those that are concerned about performance)
• Setting the IConfiguration and Logger (so that it doesn't have to pre-build the service builder
• Altering module names to exclude/ignore

[david-acm]

I like this idea a lot. This way the template can come with the defaults and the user is both aware of the defaults and also free to override them.

[lloydkevin]

I've done this in the past to simplify setup of a suite of similar services, so let me know.