Moving Attributes to and from the Tuple Layer

There is a set of patterns dealing with the question of how to move attribute values across the border between the two layers of an object/relational access layer –- the object layer and the tuple layer.

Forces Driving the Way you Move Attributes

The way you will move attributes from objects to queries in the tuple layer and from the tuple layer to your objects attributes is influenced by the programming language you use. In C++ private variables are private, and unlike Smalltalk, there are no >>instVarAt methods to get hold of private instance

Therefore C++ techniques have to be based on code generation or hand written methods in the object layer (that is, methods which the persistent objects need to implement). This is called a push down approach, because the objects are pushing their content to a lower layer. Smalltalk offers rich possibilities to get information out of objects regardless whether it is public or private, so you can economize on code quantity (no code is good code) and write access layers that resemble a meta system (see the Reflection pattern [Bus+96]). A generic mapper can encapsulate all the mapping meta information and pull the objects' information down to the lower layer and stuffs it into queries it generated from the mapping meta information at run-time.

Pattern List

Multilayer Class: This pattern provides a solution to the question: How do you design the communication between the layers without extraordinary effort in C++? You do this by generating the code to access the database into separate methods. These methods use the tuple layer directly, without any further decoupling. This pattern Was rated a last resort pattern at PLoP96 [Col+96b]. A last resort pattern is one that is in broad use in absence of better solutions.

or_multilayer.gif (12268 Byte)

Figure 11: Structure of the Multilayer Class. Shaded parts denote methods and attributes
of the upper layer (object layer). Dashed parts show lower layer (tuple layer) members

Your object's method protocol has a lower level protocol called database which contain everything needed to push down its attributes The pattern provides a proven and often used solution (for example in the POLAR Framework or the HYPO Framework [Bar+95,Kel+98b]) to do things the C++ way. Bobby Woolf, our smalltalking shepherd, was simply disgusted.

Class Broker: Is a way to do things more the Smalltalk way by concentrating the mapping for a class in a separate Broker class (see the unofficial version of [Bro+96]). A similar pattern has been described as "Strong Layering" [Via+97]. Impedance Mismatch Resolvers are also a form of Class Brokers. See also [Hei98, Section 5.4.]

Figure 12: The DBFooMgr is a per Class Broker, which is called by the Foo Object to fetch some attributes. The DBFooMgr will call the tuple layer's Physical Views to obtain the data from the database [Via+97].

Central Broker: Yet another way to do things in reflexive languages like Smalltalk is to build a central broker that evaluates classes' meta information, uses >>instVarAt to pull out the attributes and push them into query objects, generated from the mapping meta info. TopLink [TOP97a,TOP97b] uses this approach. The Central Broker is a Singleton [GOF95]

-> on to Mapping Objects to Tables

-> up to the Contents Page