Hi,

I'm looking for a best practice to design my domain model and sharply, to design object associations.


My domain model is quite complex (more than 150 objects). At first sight, when I need to add to object A an association to object B, I add a property to A of type B.

A
{
B b;
}

But, sometimes, when B and A are not in the same package, I would like to reduce dependency. Therefore, I would go to :

A
{
int bId; <-- integer to identity of B
}

Is it a good practice ? Do I keep full B?

Last but not least, If I choose this strategy and if I want to get a list of Products (which are linked to category), and can I write a Find Method where the grid gives me Products details and Category Name. Not easy because A contains only Id to B, not details. So, do I need to find each category ?

Hope you can help me !

Thks

If you just keep the foreign key in the associated class and not the whole B then I think you wont be able to utilize the hibernate association features.


I think, if A is associated to B then there IS a dependency between the two classes which means the package also need to be dependent or put both the classes in same package. You have to make either of the above decisions rather than avoiding the code dependency when the dependency is there in your business model.


So I think you should be keeping the full B


Yes you can always write the find method. But as you said this wont be straight forward. You will have to issue an join HQL for getting the Category name of a Product.

I agree with littypreethkr: Even if you replace your B with the id of B, it is a dependency, not directly but the value of your foreign key depends on B, so you have a kind of transitive dependency.
The difference is, that in that case, you have to manage all associations by yourself instead of letting an or-mapper do it for you. So why not keeping B in A with all the nice features of an or-mapper, like transitive persistence and so on.