Avalon's Story

First things first, what is Avalon?

This isn’t a simple question but here’s the story—Avalon is about component - container programming. You can often break a bit of software up into various “components” which are also sometimes referred to as “aspects” or “services” (in that the component provides a service to other components). Think of an automobile. You can break down an automobile into several components. The exact resolution of component break down depends on your point of view. In other words, one might see the car components as including systems like the engine, the body, the wheels, and so on. Likewise the the engine itself can be decomposed into smaller component systems. This is what I mean by resolution.

The same is true of software projects. All but the simpliest applications can be broken down into components. These components can be something like a logging system (sends messages to a log), a socket handler (handles network connections), or a particular piece of business logic (perhaps a transaction handler for stock transactions). One can easily see that in a large application there can be many components. These components will inevitably need to work with one another. This adds another layer of complexity. Without care, one quickly ends up with a tangled mess of components wired to other components in which a simple change in one can cause an ugly ripple effect through out the rest of the code.

To solve this, developers use “component oriented programming” which is essentially a method of programming where one uses a number of techniques to control this complexity. Central to COP is the idea of a container which does the dirty work of managing component inter-dependencies, lifecycle management and configuration. Since control is then in the hands of the container instead of the components this design pattern is often dubbed Inversion of Control.