Java.next -- Four languages that represent the future of Java
Blogger Stuart Halloway has begun a series of posts on trends that point to the future of the Java platform. In his first post, he compares Clojure, Groovy, JRuby, and Scala -- four wildly different languages that nonetheless all play together in the JRE. Find out what unites these languages and what they can tell us about the future of Java-based development ...

Newsletter sign-up

Sign up for our technology specific newsletters.

Enterprise Java
View all newsletters
Email Address:
JavaWorld.com > Java Standard Edition >

The power of table-oriented programming

An introduction to Butler

By Fredrik Bertilsson, JavaWorld.com, 10/18/04

When object-oriented programming languages began to be used in enterprise applications, designers had problems fitting the object-oriented model with the relational model. In the object-oriented model, data is encapsulated. The opposite holds true in the relational model: data is exposed and not encapsulated at all. From this, many designers concluded that if relational databases could not be avoided, they should be as well hidden from the business logic as possible.

The dream for object-oriented developers was an object-oriented database. But such databases have failed to gain a large market share, and, most likely, object-oriented databases will never win over relational databases. These days, most developers, even object-oriented purists, admit that, in most cases, relational databases prove superior to object-oriented databases.

Despite the dominance of the relational database, the mainstream persistence frameworks (Enterprise JavaBeans (EJB), Java Data Objects (JDO), Hibernate) refuse to model objects in a relational database. All relational databases are built from tables, columns, primary keys, foreign keys, records, queries, etc. But none of the mainstream products has an object model that corresponds to these entities.

An alternative model, the table-oriented programming model, allows the application source code to be aware of the actual database structure instead of hiding it in a mapping layer deep in the application stack. Many enterprise applications have a lot of CRUD-related (create, read, update, delete) logic, and developing CRUD functionality is much simpler if the database structure is not hidden.

One argument for having an object model that doesn't correspond with the actual database structure is that the business logic should remain the same even if the database structure changes. But this argument neglects the fact that much business logic is implemented in a relational database schema. Changing the database schema will, by definition, also change the business logic.

One consequence of this refusal to model a relational database's real structure is an extra layer of abstraction. Table, columns, and foreign keys must be mapped to classes, properties, and associations. In most cases, there is one class for each table, one property for each column, and one association for each foreign key. Besides, SQL must be reinvented (Hibernate Query Language (HQL), JDO-QL, EJB-QL, etc). Why bother adding this extra layer? It adds complexity and provides few additional features.

A big advantage with table-oriented programming is its ability to create data-aware GUI components. If you are making a Swing application that shows and/or updates data from a database, JTables, JComboBoxes and JFormattedTextFields connected to the database can save a lot of time in development. For Web applications, a data-aware tag library would also speed development. None of the mainstream persistence frameworks have this possibility, but data-aware components fit very well into a table-oriented framework.

Discuss

Start a new discussion or jump into one of the threads below:

Subject Replies Last post
. Why another query language?
By Jesper 		17 04/14/07 02:37 PM
by Anonymous
. Some comments
By johnzoet 		0 04/07/07 12:12 AM
by Anonymous
. The power of table-oriented programming
By JavaWorld 		8 04/06/07 11:29 PM
by Anonymous
. Tables and Objects are *different*
By Anonymous 		3 04/06/07 06:15 PM
by Anonymous
. Some questions
By johnzoet 		1 03/01/06 10:33 PM
by Anonymous
. I could not disagree more
By Anonymous 		1 10/29/04 12:19 PM
by Anonymous
. Where does the logic go?
By Llucifer 		1 10/23/04 01:03 AM
by Anonymous


Resources