Jon Tirsen在他的weblog里说，他看到一个叫PicoContainer的有趣项目，并立刻投身其中。这个自称“IoC（Inversion of Control）type 3”的微容器有什么吸引人的魅力？
PicoContainer / NanoContainer I've recently joined two new projects:
The founders of the project are Paul (AltRMI, Enterprise Object Broker) and Aslak (XDoclet, MiddleGen). Actually they pair-programmed most of it at Paul's place and a lot of beer was involved. The end result: a neat, simplistic and wonderfully TDDed piece of work. Joe (SiteMesh, QDox), my unit-testing guru, is also in on it.
It's basically an Inversion-of-Control-container/framework/micro-kernel. Pico will be the simplistic micro-kernel and Nano will be a bunch of containers serving different purposes (most built on top of Pico).
I'm not an IoC-expert by any means, and, well, I didn't know much about it before chatting with Paul and Aslak. The cool (and quite controversial) thing is that Pico (at least by default) implements style 3 IoC, which means constructors are used to define dependencies. Smart!
I will implement some Nanning support in Nano so that aspects can define dependencies on services and the container will resolve them properly, the aspects will also be able to aspectify the components transparently. The details are far from finalized, just a bunch of semi-digested ideas. I'll give you a couple of use-cases though. An aspect implementing transparent persistence with Prevayler could retrieve it's Prevayler-instance just by declaring it in its constructor: public class PrevaylerAspect {
public PrevaylerAspect(Prevayler prevayler) { /* ... */ }
/* ... */
}
A declarative transaction aspect could declare it's dependency on a TransactionManager by:
public class TransactionAspect {
public TransactionAspect(TransactionManager transactionManager) { /* ... */ }
/* ... */
}
Put these aspects along with their services in a container, Pico does it's work and all components are properly assembled:
PicoContainer pico = new HierarchicalPicoContainer.Default();
pico.registerComponent(RemoteTransactionManagerImpl.class);
pico.registerComponent(PicoPrevayler.class);
pico.registerComponent(PrevaylerAspect.class);
pico.registerComponent(TransactionAspect.class);
pico.start();
Neat and simple. No XML, no runtime attributes, no fuss.
Another great thing is that it's brilliant to mock-test the things. Say you want to mock-test your TransactionAspect to see that it actually demarcates it's transactions properly: MockTransactionManager mockTransactionManager = new MockTransactionManager();
// ...set up expectations and so forth...
TransactionAspect transactionAspect = new TransactionAspect(mockTransactionManager);
AspectSystem aspectSystem = new AspectSystem();
aspectSystem.addAspect(transactionAspect);
TestObject testObject = (TestObject) aspectSystem.newInstance(TestObject.class);
// ...run your tests on your testObject...
mockTransactionManager.verify();
Check it, you'll like it! (2003-06-20 11:25:47.0)
无独有偶，我的另一位偶像Rickard Oberg也看上了这个项目。他在自己的weblog上介绍了PicoContainer和IOC，还为这个跟人吵起来了。这个小玩意的价值在哪里？我很信赖Oberg的见地。
Why IoC? From the comments on the PicoContainer entry it seems like people are not quite getting what's so great about IoC (Inversion of Control). "If all it does is lookup, what's the point?". To me this question is like saying "What's the point with aircraft? The only thing they do is fly", but I'll give you an example that might highlight why IoC is nice to have. Let's say you have a component A that uses a component B to do something. In the first iteration of your application both are just POJO's registered in a PicoContainer. Here's the code for A: public class A
{
B comp;
public A(B comp)
{
this.comp = comp;
}
public String helloWorld()
{
return "Hello "+comp.world();
}
}
PicoContainer will, using IoC, get a reference to B and hand it to A so that it can run. Let's say that we now change so that B is a Jini service that is located using Jini discovery. The code for A now looks like this: public class A
{
B comp;
public A(B comp)
{
this.comp = comp;
}
public String helloWorld()
{
return "Hello "+comp.world();
}
}
Looks familiar, doesn't it? But, Jini isn't all that popular these days so we changed B into a webservice and put some failover on top of it using grid computing. With all of this new high-tech stuff running the show, the code for A now looks like this: public class A
{
B comp;
public A(B comp)
{
this.comp = comp;
}
public String helloWorld()
{
return "Hello "+comp.world();
}
}
See my point? The code for the A component has not changed one bit even though the lookup and discovery infrastructure has changed radically over the lifetime of our application. This is what IoC brings to the table, and which is what PicoContainer has implemented in a such an elegant way that you don't have to read a lengthy architectural document to grasp how it works. That's the point. (NOTE: For those who want to be picky about the above example and say that changing a service to a remote one and evolve it to use transactions and whatnot which would change the code for A, all I can say is: 1) you're missing the point 2) use AOP) (2003-06-29 09:36:39.0)
