Data Flow in Dependency Injection

Question

What we have

• A complex tree model stored across multiple XML files
• Java model classes which represent the XML model
  • All classes as POJOs
  • All classes annotated with jaxb
• jaxb to read the XML files
• A tree of handler classes
  • each handler is responsible for handling a layer inside the model tree or specific elements
  • the handler classes are created using guice as DI framework

Problematic bit

Some handlers need data that is processed in layers that were parsed earlier.

example:

RootHandler
\- ChildHandler
   \- GrandChildHandler

In this example the GrandChildHandler needs the data which the RootHandler computed. At the moment the code looks similar to this:

# roothandler:
Data rootData = compute();
childHandler.handleLayer(rootData);

# childHandler:
Data childData = compute();
grandChildHandler.handleLayer(rootData, childData);

Question

How should we handle this trickle down of data in the handler tree? Is it acceptable that the methods call 'explode' the further we go down in the tree?

I was also thinking about storing the child data in singletons, but I fear that it will be unintuitive if this data changes depending on each computation from a childHandler.

The Eclipse4 dependency framework supports context sensitive injection. Do you think it would be good to create a context object which contains all the passed down data and every handler just grabs what he needs from there?

Another idea we had was to separate localized data and global data and then pass the global through different methods. My fear here is that the outside has to guarantee that the most recent global data is set.

Is there some standard solution for this? All Dependency injections tutorials just ignore bigger projects :(

Answer 1

When you start out you want to keep things clean in the sense that it feels good to pass any dependencies and keep your scope as tight as you possibly can. As your project grows you may find yourself passing along a lot of objects that you hardly ever need and they start to contaminate your interfaces.

The problem may be you have some important state you have been ignoring.

When you talk about handler classes, do they produce results? Is there a mother handler that triggers all handlers and ultimately produces a compound result? If so, you may want to have a state class with a static reference to the result tree. Then any handler class could access the intermediate "master result" and find wharever it needs there whenever it needs it.

If it is just some cases, you may be better off with a static dictionary in each handler class that produces the interesting bits, where the interesting bits are stored for child handlers to access them later. You would have to clear them though before starting the next "master handling".