Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The inverse of IoC is Control

comoyo.github.com

Post reply on HN
Print view View original

11–20 of 66 posts

Re: The inverse of IoC is Control

#11

Post by ollysb »

roam wrote: post #5

Don't use IoC if you don't need it, but I'll explain why we need it in our case: some customers require different implementations. That's where the DI part comes from -- to enable us to load a different dependency based on the customer. Now, you could provide a different bootstrapper class per customer or start building a mega class with a lot of ifs-and-buts(elses), or you specify this kind of stuff in a configurati…

There really isn't much difference between using a bootstrapper class or a spring xml file, they're still both configuration files and should be equally convenient to maintain.

One of the advantages spring gives you in your scenario is multiple options for configuring your app. So in your case you can use annotations for parts of the app that don't change and then specify the parts that are different for each customer using xml(I seem to recall you might even be able to wire up a spring container using vanilla java).

Spring actually brings a lot more to the table, properly qualifying it as an IOC container. It offers mechanisms for applying cross-cutting aspects such as transaction and security management.

Re: The inverse of IoC is Control

#12

Post by philbarr »

roam wrote: post #5

Don't use IoC if you don't need it, but I'll explain why we need it in our case: some customers require different implementations. That's where the DI part comes from -- to enable us to load a different dependency based on the customer. Now, you could provide a different bootstrapper class per customer or start building a mega class with a lot of ifs-and-buts(elses), or you specify this kind of stuff in a configurati…

Exactly, you should really think about when and if you need IoC, just like with any other technique. It can be really useful. Unfortunately, if misused, it can lead to an absolute nightmare.

The problem is that when people learn about new techniques then they end up wanting to use those techniques in their next project. It reminds me of something a doctor said to me once, "Every time a new disease is identified there's an epidemic." Meaning that when doctors have something they can now identify as the new disease they are much more likely to do so since they've just heard about it, when before they would have identified it as "flu".

Re: The inverse of IoC is Control

#14

Post by RyanZAG »

_pmf_ wrote: post #6

I found that a sweet spot between wiring-by-code and wiring-by-container-and-configuration-dsl is using a dynamic language for wiring (say, Rhino, which is very lightweigth): you have the flexibility of wiring-by-code and can easily change the configuration purely by deployment (without recompiling anything)

Just curious, but what's wrong with recompiling? If you make a typo in your Rhino file on production, your whole app is now failing. Surely it makes more sense to just take the 5 minutes to recompile (or hopefully 30 minutes and test it out in dev first)?

I don't really understand what problem using the dynamic language is trying to solve there, and you've just added in a whole new branch of different code that won't work with static analysis, and will need to be maintained in addition to your normal code.

Re: The inverse of IoC is Control

#15

Post by MatthewPhillips »

roam wrote: post #5

Don't use IoC if you don't need it, but I'll explain why we need it in our case: some customers require different implementations. That's where the DI part comes from -- to enable us to load a different dependency based on the customer. Now, you could provide a different bootstrapper class per customer or start building a mega class with a lot of ifs-and-buts(elses), or you specify this kind of stuff in a configurati…

Why not just split out the shared code into libraries and make your main() be different for each customer?

Re: The inverse of IoC is Control

#16

Post by _pmf_ »

RyanZAG wrote: post #14
_pmf_ wrote: post #6

I found that a sweet spot between wiring-by-code and wiring-by-container-and-configuration-dsl is using a dynamic language for wiring (say, Rhino, which is very lightweigth): you have the flexibility of wiring-by-code and can easily change the configuration purely by deployment (without recompiling anything)

Just curious, but what's wrong with recompiling? If you make a typo in your Rhino file on production, your whole app is now failing. Surely it makes more sense to just take the 5 minutes to recompile (or hopefully 30 minutes and test it out in dev first)? I don't really understand what problem using the dynamic language is trying to solve there, and you've just added in a whole new branch of different code that won't…

In my case, I have an Eclipse-based product (toolchain for embedded development) that must be reconfigured per client or even per project (on site); i.e. it is more about dynamically creating very specific variants of a product. Using client/project-specific plugins would be the alternative for me, but this has much more overhead.

Re: The inverse of IoC is Control

#18

Post by pretoriusB »

FreshCode wrote: post #13

Do I understand correctly that the writer's main concern is that DI configuration is done in XML files, or that configuration takes place at run-time, instead of compile-time?

His main concern is that you lose static checks by the compiler, you lose clarity in the code, you lose dynamic configuration of objects AND you have to use yet another DLL (and a horrible one at that: XML).

Re: The inverse of IoC is Control

#19

Post by filpen »

FreshCode wrote: post #13

Do I understand correctly that the writer's main concern is that DI configuration is done in XML files, or that configuration takes place at run-time, instead of compile-time?

I also don't get what the author's issues are. Half of the article seems to be against XML configuration, and I don't come from a Java background but it seems that there are containers for Java that do not necessarily require an XML configuration, or is it not the case?
Post reply on HN