Friday, February 11, 2005

HiveMind and Pico Compared on java.net

Just read IoC Container Face-Off by Ken Ramirez, an article introducing the concepts of Inversion of Control and two implementations: HiveMind and PicoContainer. Curiously, Spring is not even mentioned!

I had a few minor issues with the article; I don't think it made the case very well for IoC. It confused "dependency injection" with IoC (dependency injection is an important component of IoC, but inversion of control also includes life cycle issues well beyond connecting collaborating services).

Where the article was weakest was on that exact topic: collaborating services. If you have just a main() method call a single service, IoC looks like a waste of effort. It's when you build complex systems with many moving parts ... but those individual parts are simple and testable, that IoC approach really shines.

The code to load a descriptor is too complicated; just put the hivemodule.xml on the classpath and use RegistryBuilder.constructDefaultRegistry().

Some of the terminology is about six months out of date; "singleton" and "deferred" became "primitive" and "singleton". Ken also garbled what the LoggingInterceptor does (it logs method entry and exit, not just exceptions) and missed most of the strengths of HiveMind:

  • HiveMind supports a large number of modules, which is why the extended naming is necessary.
  • It is very common to have many services implementing the same interface.
  • Not even a mention of configurations, HiveMind's most obvious differentiator from other containers.
  • No mention of factories ... many of the most interesting services in HiveMind are created dynamically at runtime.

For a supposed "face off", there was no direct comparison of the two frameworks. Here, I'll do it: PicoContainer is lighter weight, has an aversion to XML, doesn't mandate the use of interfaces, and uses constructor injection exclusively. HiveMind is driven by XML, is much heavier weight (what with support for many modules, interceptors, configurations, etc.), enforces the use of interfaces, and allows setter and constructor injection.

No comments:

Post a Comment

Please note that this is not a support forum for Tapestry. Requests for help will be deleted. Please subscribe to the Tapestry user mailing list if you are in need of support, or contact me directly for professional (for pay) support.

Spammers: Don't bother. I delete your comments and it's a waste of time for both of us. 垃圾邮件发送者:不要打扰。我删除您的评论和它的时间对我们双方的浪费