This article is more than 1 year old

The database abstraction framework strikes back

Part 2: C++ Generic Coding

In my last article, I looked at one of the differences between the C++ and Java communities; the availability of application development frameworks that have a profound effect on programmer productivity. I mentioned specifically the Java example of Hibernate and tried to identify reasons why the Java community is more innovative with this type of code reuse.

The resulting comments were interesting; particularly the point of the different histories of the two languages. C++ has evolved from C to add object oriented and later generic paradigms, the goal was always to allow exploitation of new modelling techniques and not to find patterns in application development that could be exploited. It could be argued that the contrary applies to Java. Additionally, as the Java syntax is more limited, there are less ways to solve any given problem. Consequently, there is more commonality in solutions to problem classes with Java and, as a result, the process of factorising is easier.

Some people make the point that both Java and C++ have their place and for any given problem, your choice is based on which is more appropriate to the constraints you're operating under. This is true; however, there are a wide range of problems where there isn't a fundamental driver forcing one choice over the other; for example, in web servers Java wins out because of the frameworks that exist to support the application developer. How has Java colonised this space so effectively? If the same frameworks existed in C++ then wouldn't C++ be an equally effective technology choice? As a C++ developer and enthusiast, I don't want to give up this ground so easily!

Finally, there's the argument that it simply isn't possible to implement a tool such as Hibernate without language support such as Reflection. This is where the rest of this article comes in; let's see if we can find a design for such a tool in C++. I think the ideas transform pretty naturally and we can leverage the support in C++ for generic programming to compensate for the absence of Reflection. In fact, just to prove the point I implemented a version and the source is available on SourceForge.net here if anyone wants to play with it...

Hibernate, sort-of, for C++

So, starting from scratch, what's needed to provide an abstraction layer that presents an object oriented interface to a relational data model? Well, we already know this is possible as Hibernate does it for Java, so it's simply a question of providing these capabilities in C++. However, I'm not going to assume prior knowledge of Hibernate and for the sake of respectability, I'm not going to copy blindly what those good people have done before us.

To aid the discussion, Entity Relationship vocabulary is used when referring to the relational domain and Object Oriented vocabulary to refer to the C++ interface we want to provide. I'm also going to work with the simple and classic example of a salesperson and his/her customers. In this relational data model, I have two entities, the salesperson and the customer, and there is a one-to-many relationship that associates one salesperson to his/her many customers (see Figure 1).

Figure 1: Diagram showing the Entity-Relationship Model for customer and salesperson.

So what would a reasonable object-oriented view of this data be? Well, we can imagine that there will be an object representing each entity, one each for salesperson and customer. A second question is more difficult, how do we manage the relationships? We want to be able to ask a salesperson object "who are your customers?" even though in the relational model the question is more "which customers are associated with some salesman"?

More about

TIP US OFF

Send us news


Other stories you might like