Object-Driven and Database-Driven Modeling: A Philosophical Debate

Whether to use a relational database (RDBMS) or an object database (ODBMS) for a project is beyond the scope of this book. The following discussion is oriented more towards relational databases, as these are used by most real J2EE systems.

There are two basic approaches to data modeling in J2EE applications:

• Object-driven modeling, in which data modeling is driven from an object layer (often a layer of entity beans) reflecting the J2EE application's concept of persistent domain objects
  An example is using a modeling tool such as Rational Rose to generate entity beans from a UML model and to generate RDBMS tables from these entity beans. Several application servers, including Orion and WebLogic, offer the option of creating database tables themselves from a set of entity beans.

• Database-driven modeling, in which data modeling is driven from the database schema
  In this approach, a database schema is created that efficiently represents the data to be persisted, based on the characteristics of the target database. The design of this schema will be largely independent of the fact that a J2EE application will work with it. For example, a relational schema will structure data based on relational concepts such as normalization. An example is designing an RDBMS schema appropriate to the data to be persisted (possibly using a data modeling tool such as Erwin), and then writing Java code to access and update it.

These two approaches may produce very different results.

Object-driven modeling is seductive ("We know objects are good, so let's use them everywhere"), and is usually advocated by books on EJB. Its advantages include:

• Greater potential for automation: We'll probably be able to use a modeling tool to generate Java code, rather than code data access objects manually. We'll also be freed from the requirement to write SQL or use other database-specific technologies in application code. The use of automation can deliver significant productivity gains in development.

• Greater portability: As an abstraction layer is necessary between object model and database, it should be possible to target the application to different databases without changing the object model.

When working with an ODBMS, object-driven modeling will occur naturally. When working with relational databases, on the other hand, the arguments for database-driven modeling are compelling:

• Object-driven modeling often isn't an option. The database may already be established.

• The database may prove more durable than the object model. One of the key assumptions of J2EE is that presentation changes more often than the data structures behind it. This is an argument for achieving an efficient database representation, rather than one that serves the needs of a particular J2EE application.

• Object-driven modeling usually means rejecting many of the capabilities of the database, such as stored procedures and the potential for efficient custom queries. A large company may have paid a lot of money for an RDBMS with highly sophisticated functionality. Relational databases are proven in practice unlike entity beans

• Object-driven modeling reduces architectural flexibility. It closely couples Java code and RDBMS schema. This schema can probably be created in a different database if the application is ported, but what if there are other business reasons to modify the database schema (a likelier scenario in practice)?

• Database-driven modeling will usually deliver better performance. This is often a decisive issue. In the rest of this chapter we'll see a number of areas in which object-driven modeling makes it difficult to achieve satisfactory performance when accessing an RDBMS.

• Portability between databases may not be the advantage it seems, and may not even be achievable in practice. We'll discuss this issue further below.

• Communication may be impaired within a term. Object-driven modeling disregards the input of experts in the underlying database technology. A good DBA has valuable experience in developing enterprise applications. DBAs will need to maintain and tune the system in production.

• By creating a database in the idiom natural to the database product, rather than to your object model, you are more likely to be able to leverage existing reporting tools. For example, Oracle Forms or Microsoft Access might be used to minimize the amount of work involved in implementing a simple in-house administration and reporting system.

J2EE experts disagree on whether to favor object-driven or database-driven modeling. For example, Richard Monson-Haefel, author of several books on EJB and J2EE, strongly favors database-driven modeling (http://java.oreilly.com/news/ejbtips_0500.html), while Ed Roman (author of Mastering Enterprise JavaBeans from Wiley (ISBN: 0-471-41711-4) recommends using the EJB object model to drive the data model.

Important 

I recommend database-driven modeling. Object-driven modeling is seductive, but has real dangers. Its fundamental problem is that it ignores the facts that relational databases are (a) very complex applications; and (b) proven to work very well. It's naive and arrogant (a dangerous combination!) to assume that J2EE, in a few years of evolution, has delivered a superior solution to decades of database theory and practice.

I find it helpful to think of J2EE as playing the role of the conductor of an orchestra with respect to the other component technologies of an enterprise system. Without the conductor to lead it, the orchestra exists only as a group of individuals and cannot function usefully, but this doesn't mean that the conductor attempts to play individual instruments.

Database-driven modeling may require us to write more Java code, although there will probably be much less code in total. However, it gives us greater control of both data and J2EE implementation. It leaves more scope to tackle any performance problems. Done well, it does not reduce portability.