5 ms·

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

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-profile/ 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.

galuvian 13y ago
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.
- ivan_gammel 13y ago
  I've never configured DI after deployment. Can you show a use case when it makes sense?
  - mtrimpe 13y ago
    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.
    - ivan_gammel 13y ago
      Well, that seems to be a special case. You still do not need to move 99% of your wiring out of your app.
jonhohle 13y ago
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?
- moondowner 13y ago
  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.
- ivan_gammel 13y ago
  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.
  - jonhohle 13y ago
    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.
- lmm 13y ago
  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.

galuvian 13y ago

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.

ivan_gammel 13y ago
I've never configured DI after deployment. Can you show a use case when it makes sense?
- mtrimpe 13y ago
  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.
  - ivan_gammel 13y ago
    Well, that seems to be a special case. You still do not need to move 99% of your wiring out of your app.

jonhohle 13y ago

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?

moondowner 13y ago
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.
ivan_gammel 13y ago
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.
- jonhohle 13y ago
  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.
lmm 13y ago
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.