I was wondering what is the convention about IoC/DI when building packages.
Since Umbraco doesn't come with a default implementation, I feel like I should not add any IoC container in my package as I don't want to force people to use it.
Also, if used in a solution in which someone already used IoC they might end up with 2 different IoC containers or 2 instances of the same IoC container.
What is the general approach used by package developers?
I wouldn't ship a DI library with a Umbraco package, because you never know if a user installing the package is using another library, or maybe a different version of the same library.
Luckily you can do some kind of inversion of control using the Umbraco core framework using plugin managers and ObjectResolvers.
If you look at the source of these 2 packages you can see how it connects :
https://github.com/dawoe/umbraco-booteasy
https://github.com/dawoe/umbraco-booteasy-clientbundling
I'll have a look, but I was thinking more of a standard use of IoC, to inject services intro controllers. I think using the PluginManager for this would be overkill.
I guess I'll manually inject dependencies when needed :)
I'm also a big fan of DI, but as long as Umbraco does not support it out of the box I tend to use what is available in the core when creating packages.
It makes them easier to support.
Using Dependecy Injection when building packages
Hi,
I was wondering what is the convention about IoC/DI when building packages.
Since Umbraco doesn't come with a default implementation, I feel like I should not add any IoC container in my package as I don't want to force people to use it.
Also, if used in a solution in which someone already used IoC they might end up with 2 different IoC containers or 2 instances of the same IoC container.
What is the general approach used by package developers?
Simone
Hi Simone,
think currently you have to decide if you risk it or not. There is no suggested way of doing it.
I think in v8 there will be Simple Injector used by default if I remember correctly.
Regards David
Hi David,
Did change it to Simple Injector. Last I heard was that LightInject was going to be in V8
Dave
Hi Simone,
I wouldn't ship a DI library with a Umbraco package, because you never know if a user installing the package is using another library, or maybe a different version of the same library.
Luckily you can do some kind of inversion of control using the Umbraco core framework using plugin managers and ObjectResolvers.
Have a look at the documentation here : https://our.umbraco.org/documentation/Reference/Plugins/
With the pluginmanager you can look up types implementing a interface, base class, having attribute, etc... at startup of umbraco
Then you create a object resolver that you can use in your code to get instances of the types found by the plugin manager.
Here you can see a example of the pluginmanager ; https://github.com/dawoe/umbraco-booteasy/blob/master/Sources/Our.Umbraco.BootEasy/Extensions/PluginManagerExtensions.cs
Here is a example of a object resolver : https://github.com/dawoe/umbraco-booteasy/blob/master/Sources/Our.Umbraco.BootEasy/ObjectResolvers/BootRegistrarResolver.cs
If you look at the source of these 2 packages you can see how it connects : https://github.com/dawoe/umbraco-booteasy https://github.com/dawoe/umbraco-booteasy-clientbundling
In this repo of Jeroen can see it also in action (but I guess you already had a look at that one for other reasons) https://github.com/jbreuer/1-1-multilingual-example
If you have anymore questions...shoot.
Dave
Note to self...should release more booteasy extensions.
I'll have a look, but I was thinking more of a standard use of IoC, to inject services intro controllers. I think using the PluginManager for this would be overkill.
I guess I'll manually inject dependencies when needed :)
Thx
Hi Simone,
I'm also a big fan of DI, but as long as Umbraco does not support it out of the box I tend to use what is available in the core when creating packages. It makes them easier to support.
Hopefully we will get true DI in v8
Dave
is working on a reply...