Cleaner Handler to perform service actions

[markcunninghamuk]

Is your feature request related to a problem? Please describe

In the main template we would like to be able to register extensions for the package deployer, The ideal way is to have handlers that are invoked for the specific stage.

[ewingjm]

@markcunninghamuk I know we just discussed this on the call but I think we need more context here as I can't remember what this relates to 😄

[markcunninghamuk]

Was thinking on the lines of.

public Interface IPackageDeployerExtension
{
void Execute()
}

Then each service Implements IPackageDeployerExtension leaving you with something like

App.RegisteredHandlers.ForEach(handler =>{
   handler.Execute()
}

This way you could add additional handlers without modifying the core template class. You would just register your handler and it will automatically work.

[ewingjm]

Ah, yes - this is similar to how me and @tdashworth were thinking about refactoring the services. Essentially mini ImportExtensions that handle where their own logic is supposed to trigger (as opposed to the PackageTemplateBase having to worry about all of that). Of course we'd probably need a way of having a shared context.

[markcunninghamuk]

Exactly, it makes it also less error prone as you only add the handler for new features without risking damage to other services

[tdashworth]

@ewingjm @markcunninghamuk @mjahlv I have been thinking about this recently and have come up with some questions...

Do we want to use reflection to find these handlers? If so, do we want to support different constructors or only the one?

I still think this is a good idea but I also like knowing the order in which the steps are executed within the lifecycle event. I was thinking we could create a dependency attribute that ensures those handlers are called first but then we have to build that dependency tree and ensure it's valid with no loops... This approach also removes that high-level view of which order the deployment steps are executed.

What are your thoughts?

[markcunninghamuk]

I started looking into options recently for this, One I wanted to try was MediatR, It supposedly aims to loosly couple components by turning it into more of a publish / subscribe event handler. Suggest we have a call for 20 to discuss approaches. Mark

…

________________________________ From: Max Ewing ***@***.***> Sent: Monday, January 25, 2021 09:41 To: Capgemini/powerapps-packagedeployer-template ***@***.***> Cc: markcunninghamuk ***@***.***>; Mention ***@***.***> Subject: Re: [Capgemini/powerapps-packagedeployer-template] Cleaner Handler to perform service actions (#28) Ah, yes - this is similar to how me and @tdashworth<https://github.com/tdashworth> were thinking about refactoring the services. Essentially mini ImportExtensions that handle where their own logic is supposed to trigger (as opposed to the PackageTemplateBase having to worry about all of that). Of course we'd probably need a way of having a shared context. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub<#28 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AFKLYCG7HQUAPE3ZZKPSTUTS3XCOFANCNFSM4WR7KOKQ>.

[tdashworth]

I started looking into options recently for this, One I wanted to try was MediatR, It supposedly aims to loosly couple components by turning it into more of a publish / subscribe event handler.

Suggest we have a call for 20 to discuss approaches.

Mark

Oh okay! I've used MediatR in the past which I enjoyed using. Essentially I will handle all the reflection logic for us although I used it with DI container it also handle the constructors.

I'll set something up when we're all available 😀