|
|
|
|
By "expressiveness", we mean to what extent can these containers express various logic that can be expressed in Java.
Certainly ioc container is at a higher level of abstraction and has a coarser granularity than regular Java code. But there are still logics that need to be expressed at this level and this granularity.
Pico
Pico is pretty expressive and can implement almost any logic because one can always write a new ComponentAdapter implementation. Indeed, this ComponentAdapter is everything Pico is about. The majority of the responsibility of the entire Pico container lies in ComponentAdapter.
But this expressiveness comes with a requirement of implementing ComponentAdapter imperatively in Java, which is not always ecnomic or even possible when you are working in a declarative environment such as XML.
Pico does provide a few ways of declaratively combining existent ComponentAdapter objects, such as using a ComponentAdapter as a parameter of a constructor etc. But this combinability is somewhat limited.
Spring
At the core of Spring, there's no concept corresponding to Pico's ComponentAdapter. BeanDefinition is more like a description of all the attributes of a bean in the configuration file.
Straight-forward as it is, it doesn't have the inherent flexibility as that of ComponentAdapter. Therefore, the upper limit of expressiveness of Spring is pretty much visible and not easily extensible.
Yet, practically, the facilities provided by Spring today is good enough in many senarios.
Other than regular beans, Spring has FactoryBean that's intended to answer most of the expressiveness requirements.
For example, FieldRetrievingFactoryBean reads field; MethodInvokingFactoryBean invokes any arbitrary method, etc.
Yan/Nuts
At the core of Yan, the Component class is similar to the role of ComponentAdapter of Pico. By implementing Component procedurally in Java, almost everything can be done.
Yet, different than Pico, it is normally discouraged for programmers to implement Component directly.
Yan provides a general mechanism for declaratively combining Component objects to do work of arbitrary complexity. This kind of combinability makes it possible to create a declarative yet expressive xml configuration facility.
Also, to enable simple syntax and not to preclude imperative coding, Nuts allows custom tags to be defined by implementing subclasses of Nut - very similar to how one defines custome tasks in Ant. This ability complements the declarative nature of XML because there may still be case where imperative Java code is more straight-forward and more efficient.
Detailed Comparisons:
[ edit ]