Home/ Questions/Q 965557
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-05-16T02:01:03+00:00

Is there a commonly-accepted practice for designing java objects that are frequently loaded and

  • 0

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?

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    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.

    • 0