Generator-jhipster: Constructor Injection vs Field Injection?

[sdoxsee]

Overview of the issue

I'm one who has mostly used field injection but I see merit in doing constructor injection. Would it be considered desirable to update jhipster's backend to use constructor injection where possible? I know there are trade-offs both ways but my research seems to make me lean in favour of constructor for mandatory collaborators. @gmarziou, I know you think this is not worthwhile (http://stackoverflow.com/questions/38771746/why-does-jhipster-use-field-injection-and-not-constructor-injection#comment64918144_38771746). Is there a specific reason that we're sticking with field injection or is it the effort to required migrate to constructor injection? This could also be a "later" thing that doesn't need to be happening while ng2 is in progress.

Motivation for or Use Case

See http://olivergierke.de/2013/11/why-field-injection-is-evil/ and https://spring.io/blog/2007/07/11/setter-injection-versus-constructor-injection-and-the-use-of-required/

Suggest a Fix

for example, instead of

public class BankAccountResource {

    @Inject
    private BankAccountRepository bankAccountRepository;
}

do (note: @Inject on Constructor is implied with Spring 4.3. See https://spring.io/blog/2016/04/06/spring-framework-4-3-goes-rc1)

public class BankAccountResource {

    private BankAccountRepository bankAccountRepository;    

    public BankAccountResource(BankAccountRepository bankAccountRepository) {
        this.bankAccountRepository = bankAccountRepository;
    {
}

[jdubois]

That's quite surprising from the Spring team, as I thought there was a consensus on field injection - then Oliver joined SpringSource after I quitted, so maybe things have changed since that time, with all those new people.

Anyway, I'm a big fan of field injection:

• Less code (that's obvious, and that's also the most important for me)
• Easier to use: I hate to have those constructors with tons of fields. Reminds me of the times of PicoContainer & friends (and I was an Apache Avalon user).
• Totally safe: you have Spring checking there is one and only one component. And it's as immutable as constructor injection.
• No problem for testing: OK you need to know that little method that injects the field, when you do unit testing, but that's really easy (and JHipster generates the line for you). And for me unit tests should not have an impact on the production code, it should always be the other way around.
• You still have the possibility to have optional injection, using @Autorwired, which we do a little bit in JHipster. That was the big advantage of setters over constructors, so with field injection you have the best of both worlds.
• That's personal taste, but for me it follows better the Spring bean lifecycle: you create the object, then you inject the dependencies, then you run the postcontruct. Here you mix up the first 2 parts: it doesn't do anything bad, but that isn't the original idea (with setters).
• Inheritance works, even if it's not really useful in practice!

Anyway we're not going to move this, that would be a lot of work.

[sdoxsee]

Fair points. Hadn't seen any jhipster issues or documentation concerning it
so thought I'd at least bring it up to inquire. Thanks for providing your
thoughts.

On Thu, 11 Aug 2016 5:45 pm Julien Dubois, [email protected] wrote:

Closed #3968 https://github.com/jhipster/generator-jhipster/issues/3968.

—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/jhipster/generator-jhipster/issues/3968#event-753309472,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ABHncsq03_gO6us7oLWfIBXnf_hlki-Oks5qe5efgaJpZM4Jih_G
.

[vimal-prakash-outware]

I prefer to use constructor injection over field injection. With constructor injection you know when the objects are injected and it is much more readable than field injection in my opinion. Also it allows immutable and therefore thread safe objects that don't have partially constructed state. Even though field injection is lesser code, constructor is where all the object initiation that is required for the class should ideally take place.

[cbornet]

Did you look at the generated code ? We have switched to constructor injection a long time ago...