DAO Reference Inside an Entity Domain Object?

[DFielder]

So, do you even model the relationship in the parent class in that case, i.e. with a private data member of type List<Car>, for example? Would your CarCompany look like:

public class CarCompany
{
    private List<Car> cars;
    private CarLocator carLocator;

    public List<Car> getCars() 
    {
        if (cars == null)
            cars = carLocator.getCars();

        return this.cars; 
    }
}

or would it look like this:

public class CarCompany
{
    private CarLocator carLocator;

    public List<Car> getCars() 
    {
        return carLocator.getCars(); 
    }
}

The problem with the first option is that it seems redundant - should you handle relationship caching in your domain model? The second option, though, looks like an anemic model from the inside. From the outside, you still see the same behavior, namely CarCompany.getCars(), for example, but the inside is barren.

If you went to an ORM solution like Hibernate, I would think that you'd want the first option, so that Hibernate could manage that parent-child relationship. You would also have the option of dumping the CarLocator entirely and have Hibernate lazy-load the cars child relationship.

Where do you draw the line with Hibernate regarding injecting locators and letting Hibernate manage the parent-child relationships? Would you maybe have a CarCompany that looks like this:

public class CarCompany
{
    private List<Car> cars;
    private List<Factory> factories;
    private CarLocator carLocator;

    public List<Car> getCars() 
    {
        if (cars == null)
            cars = carLocator.getCars();

        return this.cars; 
    }

    public List<Factory> getFactories() { return this.factories; }
}

In this case, you'd have Hibernate manage the factories relationship and then use the DAO for the cars one.

The problem is that I've got a richly-connected domain, and I'm trying to decide where you draw the line between populating the parent-child relationships at object instantiation, whether in the data access object or in the ORM persistence layer, or using locator or DAO services to load those relationships on-demand.

Thoughts? Anyone else encounter this kind of situation?

[dr_pompeii]

Hello DFielder

thanks for the reply, i follow the fairly and nice logic of the book Pro Spring, about transactions

if i am wrong, please teach me, share information is a good practice

Manager/Model layer (BO and ADO objects)
1:
for the ADO objects i work using Hibernate, so this consist in one interface myinterfaceADO and its myclassADO (that implements the interface ADO)
here happens the CRUD logic for an entity (Worker,Customer,Payment etc etc)

2:
but for the BO objetcs
same case an interface BO(same methods that the ADO objects for example insertCustomerBO ),
an abstract class (father) that implemts the interface BO (but really the implementation not happens here) that work with the ADO services "interfaces" and lastly a Default class (concrete) that extends from the abstract class and this concrete class really implements the BO interface

so in the abstract BO have the ADO interfaces references and call the ADO methods how insertCustomerADO( ... ) in the concrete class (son of the abstract) maybe could has other methods independently of the father and other concrete class that extends from the same father too, the father should has of course the common methods for all the children, validation and call the ADO methods and other methods necessary for the business

i work with Struts/Hibernate/Spring

i hope that i was failry with this explain, my english is not perfect

regards