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
> -----Original Message-----
> From: A mailing list for Enterprise JavaBeans development
> [mailto:EJB-INTEREST@;JAVA.SUN.COM] On Behalf Of May Charles N
> Sent: Thursday, October 24, 2002 7:42 PM
> To: [EMAIL PROTECTED]
> Subject: Re: Using Entity Beans for multiple projects
>
>
> In regard to your suggestion below, it's equivalent to making
> the association between Account and Contact many-to-many.
> That solves the specific problem stated handily (I did
> mention this in my original posting), but it doesn't really
> address my question about how, generally, to manage
> structural differences from client to client. For example, we
> could make all associations many to many, which would allow
> new clients to redefine and add associations at will. Aside
> from the implicit performance penalty in this design, we
> still haven't addressed how new clients who want new fields
> which are not driving associations can be handled architecturally.
>
> In response to your other questions:
>
> Of course I'd rather redesign for the new client since I
> could apply everything I have come to know since I designed
> for the previous client. It's a lot more fun to redesign and
> rebuild than to try to patch up ailing code which is
> inadequate for new purposes. The problem is that our project
> is large enough that I don't get to make -- or fund -- those
> decisions. Ditto for IDE changes. All I can do is state my
> case for implementing redesign and let the powers that be put
> their stamp of approval or denial on my ideas.
>
> The autogenerated relationships are not all that complex, but
> there are a lot of them. Yes, I could write a code builder
> tool to go in and put corrections in the code when my changes
> get overwritten, but it seems counterproductive to fight the
> IDE when the IDEs code generators are likely to change soon anyway.
>
> Performance and change management are both important. We've
> become much more concerned about performance lately since our
> first release is not exactly a speeding bullet.
>
> >Client A - Facade/Wrapper/Container (may be a Session Bean, Entity
> >Bean, may be a Java class, may just be a logical division,
> embodied by
> >a Remote interface) Client B - Facade/Wrapper/Container (ditto)
> >Account - EB
> >Customer - EB
> >CustomerAccountRelation - EB with fields: AccountPK, CustomerPK, role
> >(String).
> >
> >And thus:
> >Client A ---> Account ----insured---> Contact
> >Client B ---> Account ----collector---> Contact
> >
> >or even:
> >Client A ---------------> Account
> > --insured---> Contact
> >Client B ---------------> Account
> > --insured---> Contact
> > --collector---> Contact
> >
> >How do you feel about creating code that is legacy even
> while it still
> >is beta? (esp. if you're upgrading your IDE soon). I'm
> unfamiliar with
> >VAJ/Websphere as an EJB enabled IDE(been a long time :); is the
> >autogenerated relationship managementent that complex to
> manage on your
> >own? Is performance paramount or is maintenance/ability to manage
> >change more important?
> >
> >
> >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 <http://www.codefoundry.com/>
> >
> >Disclaimer:
> >
> >Opinions expressed are entirely personal and bear no relevance to
> >opinions held by my employer. Code Foundry Ltd.'s opinion is that I
> >should get back to work.
> >
> >
>
> ==============================================================
> =============
> 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".
>
>
===========================================================================
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".
