Should Business Objects have References to DAOs?

[sethladd]

Hello,

Follow a successful previous thread, I'd like to open a new thread. In the <a href="http://forum.springframework.org/showthread.php?t=9846">previous architectural thread</a>, we talked about what it means to move business logic into business objects, where business objects are brought to life by Hibernate, but wired by Spring.

I've got a use case that illustrates the need for the business object to have a reference to DAOs. Due to how Hibernate manages certain relationships, some business logic operations need the DAOs. I will illustrate this use case below.

My question is: How common is it to have Business Objects that contain DAOs? In the previous thread, we acknowledged that business objects, in order to perform business logic, need dependency injection. Here I ask: should we give DAOs to Business Objects?

Use Case:

A car detail shop needs to upgrade the wheels on a car. The old wheels are thrown away, and the new wheels are installed.

Business Objects:

Car, 1:Many Wheel
DetailShop

Methods:

DetailShop.upgradeWheels(Car, Wheel[] newWheels)

or

Car.upgrade(Wheel[] wheels)

Because Hibernate will not delete objects out of persistence if an object has its reference removed, we need to managed the deletion of old objects out of persistence manually.

Car.upgrade() will look like this:

public void upgrade(Wheel[] newWheels) {
    Wheel[] oldWheels = getWheels();
    for (int i = 0; i < oldWheels.length; i++) {
        wheelDAO.delete(oldWheels[i]);
    }
    setWheels(newWheels);
}

If we were to just call

setWheels(newWheels)

, the old wheels would never get deleted from the database.

This also seems like it breaks encapsulation, since now these methods need to know the persistence details, but this is besides the point.

What do others think? Does this approach make sense? Should Business Objects require DAOs to function? Obviously, someone needs to call dao.delete().

As always, your thoughts and opinions are much appreciated!
Seth