Inject dependencies in methods or in the constructor?

If you inject during the methods than you are not differentiating the behavioral abstraction from the concrete dependencies. This is a big no no :). You want to depend on abstractions so you are not coupled with the dependencies of your classes dependencies . . .

Since your constructor would not be there in any interface that your concrete class supports than you are not coupling to that dependency. But the method calls would have that issue.

Here is a good article on this tiopic:

http://chrisdonnan.com/blog/2007/05/20/conquest-through-extreme-composition-glue-part-2/

By not injecting the dependency at each method you then force each caller to know or retrieve the dependency.

Also from a tooling standpoint there are many frameworks available (at least in .NET) that enable or make constructor injection much easier to do. This should not sway the decision but makes it much more attractive.

Good luck.

The major benefit of constructor injection is that it allows your fields to be marked final. For example:

class Foo {
    private final Bar _bar;

    Foo(Bar bar) {
        _bar=bar;
    }
}

The following page has a great list of the pro's and con's: Guice Best Practices:

Method injection

• + Isn't field injection
• + Only thing that works for some strange edge cases

Constructor injection

• + Fields can be final!
• + Injection cannot possibly have been skipped
• + Easy to see dependencies at a glance
• + It's what the idea of construction is all about
• - No optional injections
• - Useless when DI library can't do instantiation itself
• - Subclasses need to "know about" the injections needed by their superclasses
• - Less convenient for tests that only "care about" one of the parameters