| IoC is an usual technique and buzzword from the C#/Java + XML + ORM + SQL hell. There are many programmers working in the Real-World [TM], powering great apps and webapps, using saner technologies who have never heard of the term. I wrote my own IoC container (a clone of picocontainer IIRC) to see what the fuss was about when the term started to become fashionable. No big deal. It can help reproduce various states (for examples in testing environments) to more easily test your app. Sure people will say: "You need an IoC container to do DI, what you're talking about is DI, not IoC". But, fundamentally, it is once again related to "state" and the difficulty to recreate a state in {dev,pre-prod,prod,whatever}. So it's once again a "solution" missing the bigger picture. Sure, people stuck in the "stateful OO" mindset will love IoC and, honestly, if you're stuck in such an hell IoC can be useful. With the caveat that IoC makes it much harder to reason about what's going on when some shit hits the fan. "Every problem can be solved with another layer of abstraction, except the problem of too many layers of abstraction" But there's light at the end of the tunnel. There are other ways to design great apps. And to make you feel even better: being "smart" as nothing to do with knowing every technology out there ; ) |