Passing injector instance everywhere ?

[Joerg Stoever]

Hello,

do I understand the documentation correctly in that everywhere I want something injected, I have to pass my Injector instance ? As in:

class A {
    public A() {
        B b = injector.resolve(B.class);
        b.setInjector(injector);
    }
}

class B {
    private C c;
    public void setInjector(Injector injector) {
        c = injector.resolve(C.class);
        c.setInjector(injector);
    }
}

class C {
    private D d;
    public void setInjector(Injector injector) {
        d = injector.resolve(D.class);
        d.setInjector(injector);
    }
}

... all the way down to the lowest class in my object graph that needs injection ?

[jan]

Hi,

On Thursday, 2 May 2013 12:18:56 UTC+2, Joerg Stoever wrote:

do I understand the documentation correctly in that everywhere I want something injected, I have to pass my Injector instance ?

... all the way down to the lowest class in my object graph that needs injection ?

No. 

In the example it shows the init where at some point and once you create the context and resolve the root of your graph. 

Somewhere the injection hast to begin. But of cause you do not inject the Injector in your instances. And usually you shouldn't manually resolve anything else than the root instance.

Maybe you are confused by the lack of setters ? Add the constructor that asks for all dependencies as constructor parameters. When this type is constructed by the Injector it will try to inject those dependencies.

So you have to bind them, otherwise you will get a exception that a dependency couldn't be resolved. 

Note: If you actually need the Injector somewhere because there are dynamically changing dependencies you could just add the Injector itself as a constructor parameter and it will be injected without binding something explicitly. 

But you should just make use of this if you understand DI in depth and how silk specifically works and you for example build kind of a "plugin" for it or something similar and you see this as the last possible way.

In you example the classes A,B and C could look like:

class A {
  A(B b) { ... }
}
class B {
  B(C c) { ... }
}
class C {
  C(D d) { ... }
}
class D {
  D() { ... }
}
 

Than in a simple case you have a Module that is a Bundle as well:

class RootModule extends BinderModule {
  void declare() {
    construct(A.class);
    construct(B.class);
    construct(C.class);
    construct(D.class);
  }
}

In the init code you that start with:

Injector injector = Bootstrap.injector(RootModule.class);
A root = injector.resolve(dependency(A.class));
A.b.c.d.something();// will work since all instances in the graph have been created

Cheers,

Jan

[Joerg Stoever]

Thanks, that makes a lot more sense than what I thought ;)

[jan]

On Friday, 3 May 2013 10:28:07 UTC+2, Joerg Stoever wrote:

Thanks, that makes a lot more sense than what I thought ;)

Maybe you can point out what part of the docs made you think wrong first so that I can improve it. Thanks.  

[Eric Schwarzenbach]

In my opinion, and this is from the standpoint of having just started to look at your documentation and example code, a major stumbling block to getting a grasp of some of this, is that your Injector code is never shown in a real context. While your other examples are whole classes the Injector code is always just shown floating. Where in my app ought it go? (I realize the answer is probably "it depends" but some simple example possible answers with caveats is better the leaving it unanswered.) Having that in the context of a real example app would be very helpful (from my point of view, preferably a simple webapp, but that may be my bias).

[jan]

Hi Eric,

yes it depends. Think of the Injector as an container for managed objects. Where you put this depends on the application but it is almost always in the "bootstrapping" part of the code where also the container is created from the root Bundle. After one has asked it to create the root application object, the Injector could often be "forgotten". You work with you application as if you had created it manually. But I can add a example soon. If you have something specific in mind, please let me know.

One thing that might confuse you is maybe the idea that you could inject into components or actions of you webapp. Such a extension does not exist for any web-framework. When using such a framework, of course you need to hook in the injection somewhere in the creation process of such objects that are usually created by the web framework for every request/session. Often web frameworks have a interface that allows to hook in to do initialisation of such instances. 

Jan

[Eric Schwarzenbach]

Hi Jan,

Thanks for the reply. (Sorry I didn't see it...I kind of moved on from looking at Silk since I decided to just manually create my objects for now.)

I think some of what makes it unclear to me, is that I actually have only a fuzzy idea of the situation where I really need a DI framework in the first place. Yes, I've used it in other frameworks, and I've read Fowler's article, but still this fuzziness remains because, frankly I've never arrived at the need for DI framework organically. I've always used them in the context of a web framework which just assumes it is desirable and needed and saddles you with one as THE way to construct your app. I think in this day and age, this is true for most developers--it is so taken for granted and built into every web framework that most developers do not truly have an understanding of when it is or isn't needed.

So while I'm not requesting this (as I said I've decided to more forward without DI at all, until such time as I actually wind up needing it...and IF that ever happens Silk will be the first tool I look to), I think an example that actually convincingly shows a need for DI might be the best way of making clear where the parts belong. I realize though that most people learning how to use Silk do not need to be convinced they need DI or they would not be there, however I think most are probably just following the conventional wisdom that they need DI and do not in fact really know.

And to be honest the only justification I can concieve of for it is when your dependency graph is so complex that solving for the order in which initialization and injection needs to occur without being cyclic, is a difficult problem. In which case, I suppose that wouldn't work well for a tutorial example. Perhaps an example that does initialization manually, side by side with how you replace that with Silk.

Cheers,

Eric

[jan]

Hi Eric,

I think you are doing it right *not* to use a DI library or framework as long as it can be avoided. 

It might be very unpopular but I think a good developer is always able to keep things simple enough to not need it from a technical perspective. 

Why then Silk ? When I started I thought, _how hard could it be?_ to do anything better than spring or guice, those 2 you are typically _forced_ to use at your day job. 

This grew bigger and finally I had put together a DI library as I wanted to have it, when working in one of this typical oversized projects with to many developers and to much XML and annotation magic.

Even though I think Silk is the most elegant and simple to use and scale DI tool out there I got quite sure that if you are doing it right you shouldn't need any DI tool at all.

One exception thou I recognized are political motivated features and decisions that sadly happen more often in our day jobs than we would like to. 

A system that is sold as a bunch of "modules" to customers will quickly cause bootstrapping hell due to the unlimited possibilities of assembling the product.

Than a tool like Silk might actually improve the maintainability over something wired manually. 

Finally we as java developers have to admit that it is the rule not the exception that we work in a team that is to big and has to many "juniors" in it to not mess up a "hand crafted" solution.

This is again where mostly politics mess up the systems we build. The agile "culture" has done its killing stroke in may places.

My hope would be that Silk can help improving the situation in such projects by offering an alternative to the mainstream DI frameworks that actually allows and has the goal to get rid of the "need" for a DI tool at all.

Cheers,

Jan