{scrollbar}

Tapestry IoC Overview

Even today, with the overwhelming success of Spring and the rise of smaller, simpler approaches to building application that stand in sharp contrast to the ultra-heavyweight EJB approach, many people still have trouble wrapping their heads around Inversion of Control.

...

Using unit tests, in collaboration with tools such as EasyMock, you can have a code base that is easy to maintain, easy to extend, and easy to test. And by factoring out a lot of plumbing code, your code base will not only be easier to work with, it will be smaller.

Living on the Frontier

Coding applications the traditional way is like being a homesteader on the American frontier in the 1800's. You're responsible for every aspect of your house: every board, every nail, every stick of furniture is something you personally created. There is a great comfort in total self reliance. Even if your house is small, the windows are a bit drafty or the floorboards creak a little, you know exactly why things are not-quite perfect.

...

To extend the metaphor, a house in a town is not alone and self-reliant the way a frontier house is. The town house is situated on a street, in a neighborhood, within a town. The town provides services (utilities, police, fire control, streets and sewers) to houses in a uniform way. Each house just needs to connect up to those services.

The World of the Container

So the IoC container is the "town" and in the world of the IoC container, everything has a name, a place, and a relationship to everything else in the container. Tapestry calls this world "The Registry".

...

Tapestry IoC's job is to make all of these services available to each other, and to the outside world. The outside world could be a standalone application, or it could be an application built on top of the Tapestry web framework.

Service Life Cycle

Tapestry services are lazy, which means they are not fully instantiated until they are absolutely needed. Often, what looks like a service is really a proxy object ... the first time any method of the proxy is invoked, the actual service is instantiated and initialized (Tapestry uses the term realized for this process). Of course, this is all absolutely thread-safe.

...

In fact, when a Tapestry web application starts up, before it services its first request, only about 20% of the services have been realized; the remainder are defined or virtual.

Class vs. Service

A Tapestry service is more than just a class. First of all, it is a combination of an interface that defines the operations of the service, and an implementation class that implements the interface.

...

Tapestry IoC also has support for other configuration that may be provided to services when they are realized.

Dependency Injection

Inversion of Control refers to the fact that the container, here Tapestry IoC's Registry, instantiates your classes. It decides on when the classes get instantiated.

...

In any case, injection "just happens". Tapestry finds the constructor of your class and analyzes the parameters to determine what to pass in. In some cases, it uses just the parameter type to find a match, in other cases, annotations on the parameters may also be used. It also scans through the fields of your service implementation class to identify which should have injected values written into them.

Why can't I just use new?

I've had this question asked me many a time. All these new concepts seem alien. All that XML (in the Spring or HiveMind IoC containers; Tapestry IoC uses no XML) is a burden. What's wrong with new?

...

Meanwhile, the QueueWriterImpl class no longer needs the instance variable or getInstance() method, and the TableMetricProducer only needs a single constructor.

Advantages of IoC: Summary

It would be ludicrous for us to claim that applications built without an IoC container are doomed to failure. There is overwhelming evidence that applications have been built without containers and have been perfectly successful.

...