CODEWITHSUNDEEP
botframework
oflahero
oflahero

Reputation: 1330

How is Autofac's IComponentContext being resolved in a BotBuilder sample?

A pretty specific query I know but one that hopefully applies more generally to the use of Autofac across the BotFramework SDK.

In the 'ContosoFlowers' sample, the DialogFactory class receives its 'scope' member, an Autofac IComponentContext, as its one constructor parameter.

However, I'm mystified as to where this comes from. I have an irrational hatred of DI anyway, but I still can't find some bootstrapper/service locator/module etc. that somehow links this to a concrete implementation. No obvious module. Is it baked in somewhere in the BotFramework code?

Also, can I ask what the purpose is of having all this DialogFactory.ContosoFlowersDialogFactory.Create() layer is? Say for example, when calling this.dialogFactory.Create<FlowerCategoriesDialog>()? This I assume is to avoid having to 'new' the dialog, and because the DI scope isn't available to the calling dialog? In that case, why have this factory injected into the RootDialog and not the IComponentContext scope itself?

Apologies if noob questions (very likely). Also please advise if there's a better place/forum for specific BotFramework samples code queries. Thanks!

Upvotes: 0

Views: 673

Answers (1)

Ezequiel Jadib
Ezequiel Jadib

Reputation: 14787

Good questions! Let me try to address them:

  1. IComponentContext. There is no registration/bootstrap of that interface. They are automatically provided by Autofac (see here).
  2. ContosoFlowersDialogFactory. Your assumption is correct, the idea of having a dialog factory is to avoid having to 'new' dialogs manually, as that adds limitations around unit testing for example. Certainly, the approach you are suggesting is valid; and nothing prevents you to use the IComponentContext in the dialogs (please not that not only the RootDialog is using the factory, but also the other dialogs such as the SettingsDialog or the SavedAddressDialog). The reasons of having that layer could be subjective, so I would just provide you my point of view here. IMO, having these layers contribute to have a cleaner code and to avoid having DI's specific components across the application. In this scenario, the DialogFactory is the responsible of dealing with the DI layer, allowing you; to change the DI mechanism if you want; without having to update all the other components; or even in the case of a breaking change on Autofac; you will have just to deal with it in the factory. If I have to choose, I would prefer not having direct Autofac.* dependencies in my dialogs.

Upvotes: 2

Related Questions