The Long and the Short of Mapping Chains

Choosing the right combination and granularity of mapping functions is an important and creative process that often involves difficult trade-offs. So, how does one decide? There are multiple factors, but first, let's just deal with the "length" of the link.

Constructing mapping chains from several short-hop mappings can be especially useful if one can combine existing mapping functions into a larger, more powerful mapping function. This is particularly true if reuse of mapping functions generates revenue (either the fiscal kind or the "reputational" kind).

Short-hop mappings can also help in avoiding redundancies that can occur in long-hop mappings. For example, consider a model whose objects communicate without knowledge of distribution. A single long hop would have to build a single mapping function that took a mark indicating whether a given component is local or remote, and then generate the code. Of course, there will be a good deal of commonality between local classes and classes with proxies, yet that commonality is not explicitly exploited. Rather, it's hidden inside the mapping function. We could instead build an explicit intermediate metamodel containing remote and local accesses; build a mapping function that knows about local and remote access; and then build another mapping function that generates the classes.

These metamodels can simplify the individual mapping functions, even to the extent that the effort to implement multiple, simpler mappings becomes less than the effort to implement one long-hop mapping. It's also more likely that a short-hop mapping can be reused in other contexts, whereas a long-hop mapping is specific to its source and target metamodels.

A viable option is to arrange a number of metamodels in an abstraction hierarchy, a tree within which the leaves are the metamodels for the target platforms and each of the nodes factors out all commonalities of the metamodels from which they abstract. In this case, each mapping function only has to implement the relatively small steps between metamodels. The mapping functions, and the metamodels on which they depend, are then portable across projects. The domain chart of Figure 11-1 shows an example of an abstraction hierarchy.

The good thing about building up this hierarchy is that once a single reasonable path has been defined for one particular target platform that should be addressed first, one doesn't have to design all of the other metamodels of the tree before anything can get started. If you have a model for some abstract component-based platform that can be realized on top of either J2EE or .NET, say, it's better to take two hops, first from the business model to the component-based model and then on to J2EE source code or a J2EE model. This way, you can start development for J2EE, and simply plug in the .NET model later.