Registering Notification Events within an IComposer

[cornehoskam]

Is your feature request related to a problem? Please describe.
Currently the only (recommended) way to register NotificationHandlers is through the IUmbracoCommerceBuilder. This is due to the extention method on the IUmbracoBuilder.WithNotificationEvent being marked as Obsolete. The problem however is that this means that you cannot have two seperate composers in an application registering Commerce notification handlers at the same time, as this would mean both Composers would have to call the .addUmbracoCommerce extension in order to access the IUmbracoCommerceBuilder. This will cause all sorts of trouble with the various methods and services ".addUmbracoCommerce" calls & registers.

Describe the solution you'd like
The ideal solution would be to have the Umbraco Commerce Notifications functioning the same as Umbraco's Notifications, and being able to handle & register them as 'regular old' INotificationHandlers would be the most elegant solution, instead of the custom Event implementation it currently relies on.

Describe alternatives you've considered
The other option would be to have the WithNotificationEvent method on the IUmbracoBuilder not be marked as obsolete, and/or add a functionality to the default Umbraco Commerce registration Pipeline to allow the creation of perhaps a custom implementation of IComposer (ICommerceComposer?) that has an instance of IUmbracoCommerceBuilder as it's Compose parameter instead of an IUmbracoBuilder instance that you can dynamically extend on.

Additional context
For single-applications this isn't a 'huge' problem as it would mean having to group all the various registrations in the same class. It becomes a problem however whenever you choose to create a library or package that wants to register said events for you, which it is unable to do without calling the obsolete methods right now.

[mattbrailsford]

Good suggestion, and defo something that I have noticed myself too.

Umbraco Commerce having it's own event system is really something that came from Vendr which was trying to decouple itself somewhat from Umbraco as there were a number of times in it's history where it fell fowl to unexpected changes. With it being an Umbraco product now though, I can see how it would make more sense to reintroduce that tighter coupling.

There is actually a method in Umbraco Commerce that acts as a bit of a workaround, but this is currently marked as internal, so maybe as an interim at least it would make sense to make this public.

Essentially, we have a WithUmbracoCommerceBuilder() extension for IUmbracoBuilder which returns the current IUmbracoCommerceBuilder so you can register Umbraco Commerce dependencies from within an Umbraco Builder. It's predominantly used to provide backwards compatibility if you do use those obsolete handlers you mentioned, but I think it could make sense to make it public and allow it's use in general.

[bjarnef]

I found that we can register using an composer like this while composed before UmbracoCommerceComposer:
#475

public static class StoreBuilderExtensions
{
    public static IUmbracoBuilder AddMyStore(this IUmbracoBuilder umbracoBuilder)
    {
        umbracoBuilder.AddUmbracoCommerce(v =>
        {
	    ...
        });

        return umbracoBuilder;
    }
}

[ComposeBefore(typeof(UmbracoCommerceComposer))]
public class StoreComposer : IComposer
{
    public void Compose(IUmbracoBuilder builder)
    {
        builder.AddMyStore();
    }
}

This seems to work when using .Add<TTask>, but it seems to cause issues if using .InsertBefore<TTask>() or .InsertAfter<TTask>() inside this composer.. I guess this is because the other tasks are not registered yet and happens later in UmbracoCommerceComposer.