Database object design in Java

Question

Is there a commonly-accepted practice for designing java objects that are frequently loaded and saved to and from databases?

The approach that I'm using now is to have one main database object which opens a connection to the database. Anywhere in my application where I need to load or save objects, I create a source interface for loading and saving. For example, I might do something like this:

public interface CalendarSource {
  public Appointment[] getAppointmentsForMonth(int year, int month);
  public void saveAppointment(Appointment appointment);
}

Then I would implement that interface on the main database object. Any sub-data is also loaded at the same time into member objects inside the main objects. Like if there's a list of guests for each appointment. This works well, since all of the data I'm using comes from one of two databases, so I keep two database connections around, and each source is implemented by one of them.

The problem is that this just seems unwieldy at times. It's confusing how to handle ID values, since I really don't want to add them to my objects. It also requires one database connection to implement several different interfaces. Effectively, my database package has to rely on almost every package in the project because it implements all of the interfaces. This does make sense on a certain level, but I'm wondering if there's a better way.

There are two main reasons why I chose this architecture:

• I'd like the objects that I use to not know that they are loaded or saved from a database. I might want to replace this database source in the future with flat files for portability.
• I'd like to have a good package dependency hierarchy. The database code should be isolated so a change to the database schema can be easily updated to the code.

The one problem that I run into is what to do about ID values. Since the objects shouldn't know they are database objects, they shouldn't have an ID field in them. But, if I try to write an object to the database, and I don't have the ID value, how am I supposed to know if I should do an insert or an update?

I'm also concerned about having the database package extend everything throughout the whole project. I'm constantly passing these source interfaces around. I suppose that makes sense, too.

Maybe I'm just looking for some validation that I'm doing it right, and there's not some obvious simple solution here that I'm not seeing. Don't get me wrong - everything works just fine.

Any thoughts?

Answer 1

I think the most universal pattern is the DAO pattern. That is, Data Access Object. Basically you define an interface which specifies the behavior (like basic crud operations, and specialized behavior for your domain) and then you provide implementations. For extra points you can use generics is java 5 and greater to write less code.

http://www.ibm.com/developerworks/java/library/j-genericdao.html

Its an important design choice to keep all persistence code in one layer of your application. It helps keep the code simple and clean.

From your post, you don't want to do what you are doing. Use Spring or equivalent because it will handle a lot of the code for you. It manages connections, transactions, etc.

Also, don't worry about having an ID field on your classes. While you might not consider it perfect, it makes life easier. Choose to fight the larger design fights, like doing TDD and keeping your design clean.

Answer 2

I say the easiest structure is generally something like

Create domain objects that have the fields you want.

Public class Appointment {
private Date appointmentDate;
private String locationName;
List<Person> appointmentAttendees;
}

Then you have a database that maps 1 field to 1 column... and throw it in Hibernate to go back and forth from object to database object.

Will that meet all your needs? Who knows. Depends what all you need :P

Answer 3

Do Not Roll Your Own.

Look at Hibernate, iBatis and JPA.

Toss a coin. (I like iBatis, but the other two are equally good)

Implement completely in the chosen technology.

Now that you've implemented something, you have learned the technology and can now make a rational choice to pursue an alternative or stick with the one you choose initially.

Important: Do Not Roll Your Own.

Answer 4

Your approach forward 'one central database object' and 'sub-data is also loaded' seems a direction to good design.

However, as this is java in 2010 such problems as data storage and really all related stuff around are already implemented. Whats more you have specifications like JDBC, JPA and JDO and for these specs several implementations like Hibernate, Open JPA, EclipseLink...

E.g. JPA and Hibernate is a perfect choice! You will need an xml config file where you define your database configurations(http://docs.jboss.org/hibernate/core/3.3/reference/en/html/session-configuration.html).

You can define your persistent Java Class - DB Table mapping in that xml(http://docs.jboss.org/hibernate/core/3.3/reference/en/html/xml.html) or also by annotations(http://docs.jboss.org/hibernate/stable/annotations/reference/en/html_single/).

You will use Hibernate Session/Entity manager to save your persistence objects state into tables. (http://docs.jboss.org/hibernate/stable/entitymanager/reference/en/html_single/)

For Id values: these are generated in most cases, there are several possible approach for the value generation.(http://docs.jboss.org/hibernate/core/3.3/reference/en/html/mapping.html#mapping-declaration-id)

You can stay independent from DB Tables, you can restructure, rename anytime as these can be reconfigured. For more complex changes you should check (http://docs.jboss.org/hibernate/stable/core/reference/en/html/inheritance.html)

If you change to file storage, no problem as your Java classes are Serializable classes you can save their state anytime into a File independent of the database implementation.(http://java.sun.com/developer/technicalArticles/Programming/serialization/)

Java World Hibernate Tutorial