why dependency injection in vert.x?

[JC]

Hi folks,
could somebody enlighten me why on earth should one need DI on vert.x? Only because other frameworks have it or is there some deeper reason?
Many thanks,
S

[Alexander Lehmann]

What do you use dependency injection for?

[Jez P]

Isn't this rather the same question as "why should one need DI in any framework?" The reasons why an application built on vert.x might use DI are exactly the same as reasons why an application built on another technology might. Indeed, in some ways you're kind of already doing DI by defining event bus listeners (which you could easily swap out for other implementations, just listening on the same eb addresses). 

There's no fundamental conceptual difference by defining different implementors of an interface which can be swapped in/out as desired a la DI framework (Guice/Spring) and having your application wire in the ones it wishes to use, and doing something similar for event bus listeners. In both cases the caller isn't really aware of what code is going to handle its requests, but it's a combination of the framework and the wiring which does that.

However, to answer the question I think you're asking, you might have some cases where you have logical services not communicating via the event bus, but you might still want the capability to wire those together yourself. Not every service-service interaction needs to be completely decoupled via the event bus, but it still makes sense to have a logical decoupling between those services, and that's where use of DI comes into play.

[S C]

The only place I've noticed is that Elasticsearch module requires DI via HK2.There's nothing which can be configured so there are no wiring options we should consider.
On the theoretical level, as already noted we have the bus system. If almost everybody else is using the bus (like vert.x applications are kind of expected to), where will be the composition root for DI? There will be two approaches doing almost the same thing and if I really need them both, then maybe combining them in the same application is a wrong design. I really don't get what this configuration can exactly achieve...
I have nothing against DI (maybe useful with Yoke?), but I still don't see the value bringing DI for handling vert.x modules.

--
You received this message because you are subscribed to a topic in the Google Groups "vert.x" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/vertx/WkpyvQ7xr88/unsubscribe.
To unsubscribe from this group and all its topics, send an email to vertx+un...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Tim Fox]

Vert.x doesn't require or mandate DI at all. It's totally up to the user if they want to use DI or not.

If the elastic search module currently uses DI that doesn't reflect a requirement from Vert.x, it's an implementation choice for that module.

You received this message because you are subscribed to the Google Groups "vert.x" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vertx+un...@googlegroups.com.

[S C]

Tim, don't worry, I understand completely it's the developer's choice - I just wanted to understand why. And I think I got my explanation here:
https://groups.google.com/forum/#!msg/vertx/JQQpE_zwnbY/KO7MpR9VmtsJ

...so it looks like it was "hack" to get Jersey running which somehow propagated to the Elasticsearch module. Note your honour that I'm still not happy with the idea :)

[Jez P]

" I still don't see the value bringing DI for handling vert.x modules"

I don't know the specific case for the elasticsearch module, so I won't comment on that, but I can see that you probably wouldn't want to decouple absolutely every interaction via the eventbus, and DI is a good way of decoupling without being forced to use the eventbus (where for example the processing you're decoupling carries low overhead). 

"If almost everybody else is using the bus (like vert.x applications are kind of expected to)" - this is in my view incorrect. You use the event bus to decouple verticles, but there's no reason why you should invent new verticles just to decouple processing which could be reasonably carried out by a single verticle. It's quite rightly up to the code author how they want to decouple the processing. Put another way, if your processing is small in nature, but you still might want to swap in different implementations, what's the technical need to put a message on the event bus when you can process immediately then and there?

You're implying that because the event bus is there it should be used as the sole mechanism for decoupling implementation, I don't think that's true at all. If you think in terms of putting something on the event bus as deferring a piece of processing until the event loop gets to it (which under load could be a random point in the future) then you'll see that there is a clear difference between using normal DI and using the event bus as a DI mechanism.

[Tim Fox]

BTW.. in Vert.x you can deploy verticle instances (i.e. not by specifying the class), and because of the flat classloader model would make DI much easier to use with Vert.x.... If you want to use it.

[S C]

On Wed, Jul 23, 2014 at 2:03 PM, Jez P <mr.n...@gmail.com> wrote:

You're implying that because the event bus is there it should be used as the sole mechanism for decoupling implementation,

 

My question was asked in the context of the ES module where there's no implementation switching at all - more a way to iron out some Guice compatibility issues. While I cannot but agree with you on the general terms (mostly, as this argument in a JavaScript world would be again different...), in this particular module DI looks like the legendary hammer (if all you have is a hammer...).
Anyway: thanks again for your answers, they are great :)

S

[Tim Fox]

I mean to say "In Vert.x 3.0"

To unsubscribe from this group and all its topics, send an email to vertx+unsubscribe@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--

You received this message because you are subscribed to the Google Groups "vert.x" group.

To unsubscribe from this group and stop receiving emails from it, send an email to vertx+unsubscribe@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to a topic in the Google Groups "vert.x" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/vertx/WkpyvQ7xr88/unsubscribe.

To unsubscribe from this group and all its topics, send an email to vertx+unsubscribe@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "vert.x" group.

To unsubscribe from this group and stop receiving emails from it, send an email to vertx+unsubscribe@googlegroups.com.

[Jez P]

Forgot to add, I've never yet used DI in my vert.x experimentation. However, that's more to do with the fact that my vert.x stuff is small beer. I can see that I might want "logical" decoupling without the "termporal" decoupling which the event bus also implies (i.e. you don't know that piece of code A will run immediately after piece of code B if A is triggered via the event bus). DI itself is not inherently bad, and nor is use of the event bus to achieve similar effects, but as with all things, it's horses for courses. 

[Alexander Lehmann]

I should apologize, my question was supposed to be "What do you use dependency injection usually for?"

I have used dependency injection (Guice) with Jbehave where this was a rather convenient method to configure the classes that it usually uses, but beyond that I have not quite gotten the hang of this.