Hi everyone.

"Re-use" and "Loose Coupling" needs to be considered on component based developments - Let's consider Loose coupling in the EJB world.

Suppose I have 2 objects modeled as Entity Beans - Customer and Invoice. There is a "master detail" relationship between these 2 objects - A customer may have 1 or many Invoices and an Invoice must belong to one and only one customer.

Now Let's try to model this in the "best" possible way. we design a generic Customer Entity Bean, identifying all the attibutes and methods - We do the same for the Invoice Entity Bean. But how do we model the relationship???

1) we could have "tight coupling" and place the relationship in the 2 Entity beans - say a getOutStandingInvoices(), getPaidInvoices() and getAllInvoices() in the Customer bean. Each of these methods would effectively call finder method(s) in the Invoice bean, populate and array - and we could use Lazy Loading etc etc

Equally well, in the Invoice bean, we would have appropriate finder methods as mentioned above, as well as a method getCustomer() which would perhaps invoke the findByPrimaryKey() of the Customer bean.

This is deemed tight, in the sense that we have methods and data attributes in these Entity Beans that may not have meaning in another application - hence not reusable.

So - what are the alternatives?

2) Well, we could model the relationship using a session EJB, perhaps as part of a facade design pattern - This would contain all the methods mentioned in 1, as well as the appropriate "finder-type" methods.

So is this a better solution?


3) I have a number of concerns with solution2:

a) I'm instantiating extra beans (may impact performance)

b)Assume that typically, a user will retrieve a customer and unpaid invoices and work on these for long periods, querying, modifying, re-quering etc etc. Unless I use a stateful bean, I cannot cache the results of the relationships between the 2 entity beans - in other words, if the getUnPaidInvoices() returns 20 Invoice Entity Bean references, option 1 allowed me to cache those in the Customer object, whereas option 2 only allows me do this if I specify the session bean to be stateful.

And -stateful session beans can be a scalability issue.


So - what does a guy do?

Thanks for your help

PM

If you're using CMP you have to model the relationship with Entity Beans as well. So there is no different between the solution 1 and 2.

Look at my relationship's diagram:
http://openuss.sourceforge.net/openuss/developer/groups/bo/spec/images/relationship.html

Lofi.

It could be possible to have a standalone relationship entity bean (i.e. a standalone associative table) and let a sessionbean take care of the relationship. So you will have the following entity beans:

customer
invoice
customer_invoice

When you create a new invoice you have to make sure to update the customer_invoice table. For one to one and one to many this is expensive. On the otherhand you will get more general components.

But I really have not thought this through and what the consequences are.

/Theis.