Is this a good approach for a custom object-relational mapping in Java?

[visual-kinetic]

I'm developing a sample Java application that uses Oracle's built-in "HR" database schema. I'd like to treat table rows as Java objects. One of the tables in the HR schema, EMPLOYEES, is self-referential. It has a MANAGER_ID column which contains (if not NULL) a foreign key to another row in the EMPLOYEES table.

In object-oriented terms, the problem is how to get access to a given Employee object's manager (which is another Employee object). Eager loading doesn't seem to be a good solution, since the given Employee object's manager could also have a manager, and so on. The number of objects to eagerly load in this situation is unbounded.

What I've decided to do so far is eagerly load the MANAGER_ID field when instantiating an Employee object. Then, when the Employee's manager Employee object is requested (through a getManager() method), the latter will be lazily loaded. In code:

public class Employee
{
    private int id;
    private int managerId;
    private Employee manager;

    public int getId()
    {
        return id;
    }

    public Employee getManager()
    {
        if(manager == null && managerId > 0)
        {
            // Lazy loading!
        }

        return manager;
    }

    public void setManager(Employee manager)
    {
        this.manager = manager;
        this.managerId = manager.getId();
    }
}

So is this a good approach? The only issue I have with it is how to implement the lazy loading. It would seem that an Employee object needs a reference to its instantiator -- presumably that would be the same thing that would instantiate its manager Employee object.

Also, I know I could just use one of the many ORM frameworks out there instead of rolling my own, but I'm doing this on my own to gain more insight into the underlying process(es).

[travishein]

its kind of clunky, and not ideal to have the data access object's reference stuffed into the data bean, but perhaps you could stuff a reference to the DAO or what ever it is that invokes the SQL query into this bean, so that when the bean has a reference to the data accessor, it would be able to in the

private transient EmployeeDAO employeeDao;

/**
 * so add a second constructor that optionally allows the data accessor to stuff itself into the bean when it is creating the bean.
 * (We still have the noargs constructor for just creating a bean in the application right.)
 */
public Employee(EmployeeDAO employeeDao) {
  this.employeeDao = employeeDao;
}

public Employee() {
  // empty
}

public Employee getManager()
    {
        if(manager == null && managerId > 0)
        {
          if (employeeDao != null) {
             manager = employeeDao.findEmployeeById(managerId);
          }
          else {
             // whoops, lazy loading failed.
          }
        }

        return manager;
    }

[visual-kinetic]

Thanks for your reply, Travishein!

Actually, this effort doesn't involve Java EE at all. I thought I'd do something more basic first to get my feet wet. So my plan is to develop something with regular RMI and JDBC.

With that in mind, does my ORM approach seem better, worse, or neither? :)

[visual-kinetic]

Another way of doing this would be to simply store the foreign keys alone in the business objects. Since the client already has a connection to the server, it could fetch up the related objects on demand. Would that work better? At the very least, it seems more straightforward.

[gcalvin]

I like your lazy-loading approach. Maybe have another class that does the actual retrieval from the database, and caches the Employee objects in a HashMap as it retrieves them. This other class would have a getEmployeeById() method, which would check its HashMap cache first, then pull from the database if necessary. Would that help?

-Gary-

[visual-kinetic]

Thanks! Do you mean the approach I described in the OP, or the one in my last post? (I'm leaning towards the former, but I could be wrong.)

I like your idea about caching Employee objects that have been loaded from the database. That would help decouple the RMI server from the data-access code. If memory usage becomes an issue, the cache could have a size limit and the least-recently-used Employee objects could be removed from the cache once it becomes full.

How does that sound?