Better documentation of registration features

[eswann]

First, thanks for the awesome library. I'm mainly struggling with documentation. In my case, I'm trying to register all of my command handlers (they implement a generic interface) by all of their interfaces in an assembly. What I arrived at was:

scope.Configure(config => {
 config.Export(assembly.GetExportedTypes()).BasedOn(typeof(ICommandHandler<>))
.ByInterfaces().Lifestyle.SingletonPerScope();
});

But I was confused as to whether I should use the filter in ByInterfaces(filterhere) or perhaps use When(filterhere). I think it's great to have this flexibility and I can see where the shorthand in all these cases is really helpful, just not sure when it's appropriate to use one over the other.

Could you add some basic documentation on these registration features?

[ipjohnson]

Hi eswann,

I'm always open to adding more documentation and exporting a type set is a little thin with documentation. I'll try and add some more over the coming weeks.

To your question about what's the difference between the different options

• ByInterface(type) - Export all types that implement a specific interface
• ByInterfaces() - Export all interfaces implemented, optional type filter so you can do something like export only interfaces with a particular attribute.
• When - This allows for conditions to be put on the exports that limit when the export can be used, i.e. these classes should only be used when particular conditions are meet.
• Where - This allows you to filter out types that are being exported

your registration example could be simplified to

scope.Configure(config => {
 config.Export(assembly.GetExportedTypes()).ByInterface(typeof(ICommandHandler<>)).Lifestyle.SingletonPerScope();
});

[eswann]

Thanks @ipjohnson. In this case, I want to find all public classes that implement the generic ICommand<> interface, but I want to register the resulting types as all interfaces implemented. That's how I arrived at my approach. Does my approach still sound legit? My confusion was: does the ByInterface(filter) filter the interfaces that are registered for the type? (That intuitively sounds like it would be the case).
In any case, I'm happy to to help add doco pull requests as I understand the details. I think this is a fantastic lib and as we go more to the cloud, commodity cpu cycles become extremely important again (for now), so I appreciate what you've done here.

[ipjohnson]

@eswann my mistake your syntax is correct for the behavior you're looking for. To your question about ByInterfaces(filter) you are in indeed correct every interface in every type (as we are talking about a set of types) will be passed to the filter.

If you're up interested in doing a pr that would be awesome. Ultimately I'm looking to use docfx to generate documentation from the source, combined with some samples mixed in (I've hit a couple bugs with generating against vs2017 but I imagine it will get sorted out in the coming weeks/months).

To your point about cloud cycles I fully agree, even if you're hosting your own hardware the reality is extra cycles spent by one VM/container are cycles that can't be used for another VM/container.

[eswann]

Great, thanks for the feedback!