4 ms·

I can see how DI will be overkill for a wedding website and Javalin/jdbi/sqlite is more than enough but for most business applications written in Java you reall

I can see how DI will be overkill for a wedding website and Javalin/jdbi/sqlite is more than enough but for most business applications written in Java you really wish you had started with DI. Any DI libs you recommend for working with Javalin?

tipsee 4y ago
Hard disagree on needing a DI library, manual DI is great.
- Scarbutt 4y ago
  Disagree on using a lib? cause I guess doing manual DI is still DI.
  - tipsee 4y ago
    Yes, disagree on needing a library. The way your comment was worded made it seem to me like you were saying all serious Java applications need a DI library, I'm sorry if I misunderstood you. I prefer doing my ID manually, so no recommendation :)
    - mkingston 4y ago
      Could you be more explicit, perhaps with an example? Do you simply mean you prefer function/constructor parameters over DI?
      - erpellan 4y ago
        Calling a constructor is DI. ‘new’ is the only DI framework required. Benefits: Unbelievably fast startup time No magic No annotations, XML or YAML required No classpath scanning related security vulnerabilities Conpletely deterministic In no other language is ‘calling a constructor’ considered so complicated a framework is required. Try it!
        therealdrag0 4y ago
        It took me a hot moment to adjust after leaving classic spring Java land to a Scala shop that doesn’t use DI framework, but now I love it. I agree with what you said. It does help to keep services small so the manual DI arg passing doesn’t get too spread out and boilerplate-y. But I have worked on a dozen services here and don’t miss an automatic DI framework.
        coverj 4y ago
        I have a few questions about this approach, cards on the table I mainly deal in C# where DI (through the framework) is the default. How do you manage the initialization of all of the dependencies? Do you need some sort of "root" where everything is initialized and passed in? That was all I could come up with while keeping it testable and that doesn't sound maintainable once you build up the number of dependencies.
        rockwotj 4y ago
        I'm also a fan of the manual DI approach - I strongly dislike the magic. I think it helps if you are building test/fakes of your deps that don't really need as many sub-dependencies. Generally you in a test `@BeforeAll` construct a bunch of objects or for a program you do it in `main`. I did work on a project while I was at Google that was really big and a decade old that instead had a class with a bunch of lazy getters for each item in the dependency graph, then tests would override or reset the getters with testing versions as needed. It was a little clunky but I preferred that approach over the projects I worked on that used dagger. If you've read through the Dagger dev-guide [0] there is *a lot* in there, while the manual approach it's usually just `new` which is a really simple concept on it's own :) I think this is the right tradeoff because reading code is harder than writing code, so it's worth the extra setup. In practice I haven't seen it to amount to be an overwhelming amount. [0]: https://dagger.dev/dev-guide/ https://dagger.dev/dev-guide/
        deleted 4y ago
        [deleted]
        yCombLinks 4y ago
        What dependencies are multiplying? I organize my code so that the very top level of the api has all external dependencies injected there, there is no public classes below a single exposed class that would need to be directly injected into. The only thing I need to actually inject are things that are outside of my memory space, ie network calls, event buses, dbs. If it's not using something outside of my memory space I am just using new inside my classes, it's far easier to test. For example, if I'm adding a new feature to allow a user to change their address, I would have a single class at the top level "CustomerAddressChange" or whatever. I would inject an interface that wraps everything external, and that is the only thing that anything would be injected into. My tests would all stub only that interface. Everything else is done without any sort of DI container.
vips7L 4y ago
Any DI lib would probably work, it depends on your preferences and use cases though. I'm personally a fan of Weld since its the reference implementation of the CDI spec. https://weld.cdi-spec.org/ https://weld.cdi-spec.org/ A friend of mine built an MVC library around Javalin that uses Dagger as the DI container: https://github.com/jehugaleahsa/javalin-mvc https://github.com/jehugaleahsa/javalin-mvc

tipsee 4y ago

Hard disagree on needing a DI library, manual DI is great.

Scarbutt 4y ago
Disagree on using a lib? cause I guess doing manual DI is still DI.
- tipsee 4y ago
  Yes, disagree on needing a library. The way your comment was worded made it seem to me like you were saying all serious Java applications need a DI library, I'm sorry if I misunderstood you. I prefer doing my ID manually, so no recommendation :)
  - mkingston 4y ago
    Could you be more explicit, perhaps with an example? Do you simply mean you prefer function/constructor parameters over DI?
    - erpellan 4y ago
      Calling a constructor is DI. ‘new’ is the only DI framework required. Benefits: Unbelievably fast startup time No magic No annotations, XML or YAML required No classpath scanning related security vulnerabilities Conpletely deterministic In no other language is ‘calling a constructor’ considered so complicated a framework is required. Try it!
      - therealdrag0 4y ago
        It took me a hot moment to adjust after leaving classic spring Java land to a Scala shop that doesn’t use DI framework, but now I love it. I agree with what you said. It does help to keep services small so the manual DI arg passing doesn’t get too spread out and boilerplate-y. But I have worked on a dozen services here and don’t miss an automatic DI framework.
      - coverj 4y ago
        I have a few questions about this approach, cards on the table I mainly deal in C# where DI (through the framework) is the default. How do you manage the initialization of all of the dependencies? Do you need some sort of "root" where everything is initialized and passed in? That was all I could come up with while keeping it testable and that doesn't sound maintainable once you build up the number of dependencies.
        rockwotj 4y ago
        I'm also a fan of the manual DI approach - I strongly dislike the magic. I think it helps if you are building test/fakes of your deps that don't really need as many sub-dependencies. Generally you in a test `@BeforeAll` construct a bunch of objects or for a program you do it in `main`. I did work on a project while I was at Google that was really big and a decade old that instead had a class with a bunch of lazy getters for each item in the dependency graph, then tests would override or reset the getters with testing versions as needed. It was a little clunky but I preferred that approach over the projects I worked on that used dagger. If you've read through the Dagger dev-guide [0] there is *a lot* in there, while the manual approach it's usually just `new` which is a really simple concept on it's own :) I think this is the right tradeoff because reading code is harder than writing code, so it's worth the extra setup. In practice I haven't seen it to amount to be an overwhelming amount. [0]: https://dagger.dev/dev-guide/ https://dagger.dev/dev-guide/
        deleted 4y ago
        [deleted]
        yCombLinks 4y ago
        What dependencies are multiplying? I organize my code so that the very top level of the api has all external dependencies injected there, there is no public classes below a single exposed class that would need to be directly injected into. The only thing I need to actually inject are things that are outside of my memory space, ie network calls, event buses, dbs. If it's not using something outside of my memory space I am just using new inside my classes, it's far easier to test. For example, if I'm adding a new feature to allow a user to change their address, I would have a single class at the top level "CustomerAddressChange" or whatever. I would inject an interface that wraps everything external, and that is the only thing that anything would be injected into. My tests would all stub only that interface. Everything else is done without any sort of DI container.

vips7L 4y ago

Any DI lib would probably work, it depends on your preferences and use cases though. I'm personally a fan of Weld since its the reference implementation of the CDI spec. https://weld.cdi-spec.org/ https://weld.cdi-spec.org/ A friend of mine built an MVC library around Javalin that uses Dagger as the DI container: https://github.com/jehugaleahsa/javalin-mvc https://github.com/jehugaleahsa/javalin-mvc