Hacker News Reader

Comment by kenshiro_o | Hacker News Reader

I use spring in large scale Java projects but I rarely take advantage of the @Autowired feature because I find it very confusing as I define my pojos in XML configuration files. if I have autowired fields all over the place I have to look at source code AND XML files to understand what the heck is going on and from where a given field is autowired.

I suspect this introduces extra complexity. I have not yet had the chance to try Guice (https://code.google.com/p/google-guice/) so I wonder if it solves many of Spring's problems (one of the top issues is verbosity of configuration files).

View on HN

From Spring 3 (3.1 I think it was) you don't need to do configuration with XML. Current version (Spring 4) even supports configuring Spring Security with no XML at all. You can configure everything in Java and use profiles (@Profile) when you have multiple configuration scenarios. http://spring.io/blog/2011/02/14/spring-3-1-m1-introducing-p...

Also, don't forget that you can use @Resource (jsr250), not only @Autowired.

The author also says:

> So reuse and decoupling are opposing forces. I find myself siding with decoupling.

The developer has to make a balance between reuse and decoupling. In my opinion everything doesn't have to be 100% reused or decoupled.

Auto wiring is great for test code. Most of you need to know about the test is contained in the testing class.

But I don't like using auto wired in the main code because it means I am required to use that wiring for every use. I find that we want to use classes in a few different ways, and keeping the dependency definitions and configuration values in the XML decouples it from the code and increases both reusability as well as exposing the XML configurations after deployment so that a recompile isn't required in the field.

I've never configured DI after deployment. Can you show a use case when it makes sense?

Different DB drivers and connection pool setups for example.

Taken to extremes I've also used Spring to configure a rudimentary ETL framework for example, where the entire pipeline could be (re-)configured post release.

Well, that seems to be a special case. You still do not need to move 99% of your wiring out of your app.

But why would you want to mix your config and code? When does it make sense to lock these values at compile time, but also use an abstraction layer which suggests these values are configured at runtime?

There's no sense at all in putting configuration of DI separately from the code. Normally, 99% of DI configs are not environment-specific (if this is not the case, "Houston, we have a problem"). In most cases you ship your software not like IKEA, but like Boeing - already assembled and ready for use. The customer (possibly, internal one) has to fill the fridge with meals for passengers and tanks with fuel, not to assemble the engines or avionics.

Wiring objects together and configuring applications are tangentially related. Both can be done in Spring config, both can be done without Spring config, both can be done at compile or runtime.

Dependency glue (wiring) in runtime config helps keep objects decoupled, makes test writing easier, and eliminates any dependency on a specific IOC framework. Whether or not the wiring config comes boxed with the code or not is a completely different concern.

I prefer to configure in code because that way I can reason about it in the normal way I reason about code, or I can use code to solve problems in the usual way. E.g. I can "find usages" on a constructor and expect to find where the object is constructed. If there's some common aspect to the construction of several different objects, I can factor that out into a helper method, the same way I would with any other piece of code.

You can still have .property files for the values of the configuration fields (e.g. API keys), and you can say with which profile (by configuring with @Profile in Spring) the application to start. With that you are still able to separate the actual configuration. As I see it, the point is not to clutter yourself with beans in xml files.

I consider @Autowired and bean config in code as harmful. It also seems like one of the main things Spring was all about n the beginning - decoupling your application from the configuration framework - is now come full circle to tight coupling with Spring. Not only that, but code which references config files for one spaghetti mess of code and config that is a pain to test. More and more I run into library packages with direct dependencies on Spring config - and it makes integration painful.

I'd be happy to see Spring config in a format other than XML (JSON, YAML, whatever), but even more than that, a complete elimination of any Spring config directly in Java files.

The latest Spring release supports a Groovy DSL for configuration: http://docs.spring.io/spring/docs/4.0.0.RELEASE/spring-frame...

Groovy? Another reason not to use Spring.

Well, you can already do java based config, which is not the same as annotation based config. As with XML config, Java based config lives outside of your application code in classes dedicated to configuration. You just use Java instead of XML, which makes things much nicer.

See here: http://docs.spring.io/spring/docs/3.2.7.BUILD-SNAPSHOT/sprin...

Reply on news.ycombinator.com