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".
