This would work. However, as I mentioned in an earlier posting, our Entity Beans
themselves have a lot of associations; your design suggests letting the Entities be
more like "dumb data" and letting the Composite objects take care of the associations.
I like the idea (provided you remember to declare a Composite object as Serializable),
but it would be expensive for us to implement at this point. Worse, it leaves our
database more vulnerable to direct SQL write access because a lot of foreign key
relationships would have to be dropped. "Just imagine" someone writing reports wants
to test against some data, and has a tendency to just insert data wantonly without
regard to the business model stipulated by the EJBs...
On Thu, 24 Oct 2002 20:24:02 +0100, Juan Pablo Lorandi <[EMAIL PROTECTED]> wrote:
>Cool, that clears up the scenario. What I'd do is
>containment/aggregation/composition of objects:
>CAEB is Client A's Entity Bean (a special kind of account).
>CBEB is Client B's Entity Bean (a special kind of account).
>
>CAEB is composed of (fields):
> AccountPK account (PK or Handle gets stored in CAEB)
> ContactPK insured (ditto)
>
>CBEB is composed of (fields):
> AccountPK account (ditto)
> ContactPK insured (ditto)
> ContactPK collector (ditto)
>
>Later on, Client C comes along and wants another Account to be
>associated to the bean:
>
>CCEB is composed of (fields):
> AccountPK account (ditto)
> ContactPK insured (ditto)
> ContactPK collector (ditto)
> AccountPK automaticpayment (ditto)
>
>And Client B's requirement changes too: he says insured shouldn't belong
>to his bean either therefore:
>CBEB is composed of (fields):
> AccountPK account (ditto)
> ContactPK collector (ditto)
>
>Or, simply remove the getters/setters from the Remote interface.
>
>Sample implementation of CCEB:
>
>public abstract class CBEB implements EntityBean {
>...
> public abstract AccountPK getAccountPK();
> public abstract void setAccountPK(AccountPK accountPK);
> public abstract AccountPK getAutomaticPaymentPK();
> public abstract void setAutomaticPaymentPK(AccountPK autoPayPK);
>
> public abstract ContactPK getInsuredPK();
> public abstract void setInsuredPK(ContactPK insuredPK);
> public abstract ContactPK getCollectorPK();
> public abstract void setCollectorPK(ContactPK collectorPK);
>
> private Account getAccount(AccountPK pk) //not for remote
>interfaces!!!!
> throws ObjectNotFoundException, RemoteException {
> //lookup home...
>
> //return Account
> return (Account) accHome.findByPrimaryKey(pk);
> }
>
> public Account getAccount() //perhaps on the interfaces--
>perhaps not.
> throws ObjectNotFoundException, RemoteException {
> return getAccount(getAccountPK() );
> }
>
> public Account getAutomaticPayment() //perhaps on the
>interfaces-- perhaps not.
> throws ObjectNotFoundException, RemoteException {
> return getAccount(getAccountPK() );
> }
>
> public void pay(double amount)
> throws AbortedException, RemoteException {
> getAutomaticPayment().deposit(amount);
> }
>...
>}
>
>
>The rest ommitted for clarity. Basically, you'd composite your
>Account/Customer objects per each customer. That allows you to reuse the
>base components (Account, Customer), with almost the same ease of use
>than when using inheritance. With a few helper classes(lookups, that
>sort of thing) and even helper classes inheritance, the code for these
>composite objects could be kept to a bare minimum
>implementation(something in the lines of)
>
>public abstract class CompositeObject { //not even an EntityBean if you
>wish
>
> private Account getAccount(AccountPK pk) //not for remote
>interfaces!!!!
> throws ObjectNotFoundException, RemoteException {
> //lookup home...
>
> //return Account
> return (Account) accHome.findByPrimaryKey(pk);
> }
>
> private Customer getCustomer(CustomerPK pk) //not for remote
>interfaces!!!!
> throws ObjectNotFoundException, RemoteException {
> //lookup home...
>
> //return Customer
> return (Customer) cusHome.findByPrimaryKey(pk);
> }
>}
>
>Then make your implementations extend CompositeObject and implement
>EntityBean. This doesn't yield control of relationships to the clients
>nor they're resolved dynamically at run time. I guess you could also say
>that this solution leverages inheritance not on the beans themselves,
>but on the relationship table.
>
>My apologies for the very bad example about people being homeless et
>all. I'm just reading too many newspapers from back home.
>
>Juan Pablo Lorandi
>Chief Software Architect
>Code Foundry Ltd.
>[EMAIL PROTECTED]
>
>Barberstown, Straffan, Co. Kildare, Ireland.
>Tel: +353-1-6012050 Fax: +353-1-6012051
>Mobile: +353-86-2157900
>www.codefoundry.com
>
===========================================================================
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message "signoff EJB-INTEREST". For general help, send email to
[EMAIL PROTECTED] and include in the body of the message "help".
