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


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.


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].

-> on to Mapping Objects to Tables

-> up to the Contents Page