I would certainly prefer an inheritance solution. I am supporting multiple clients with the same DB schema and I am using the same codebase. If I ever needed to alter an individual company's schema, I would extend the related module(s) and handle the appropriate packaging in the build script. Of course, if the variations become significant, inheritance would definately become more complex. Although, if the application logic is generally the same for each client, the schema's would most certianly be very similar.
Kevin E. Gaasch Panhandle Plains Student Loan Center Software Craftsman Work: 806.324.4100 x4215 Cell: 806.674.1523 >>> Victor Langelo <[EMAIL PROTECTED]> 10/24/02 09:14AM >>> May Charles N wrote: > So, I invite your thoughts: > > * How are others out there managing to support multiple clients, > whose structural data needs may vary somewhat, while maintaining > the integrity of the common code all clients depend on? > We use inheritance of the java classes and create separate deployments for each customer application. > * Is inheritance a good route to pursue to solve the problem? > Based on our experience I'd say it was the only solution. Otherwise you have a maintenance nightmare with any but the most trivial classes. We have a fairly complex graph of EJBs for representing an Organization with multiple addresses, contacts, phones, notes, etc.... We have encountered numerous bugs in the past three years. It would have been a nightmare to manage completely different sources for each different deployment. > * Should I resign myself to having one giant "all-inclusive" > schema for all clients with possibly many sparsely populated > columns because they are used only by certain clients? > Only if you are stuck with your current IDE. You might want to consider XDoclet or Together. But I don't rely on automatic code generation. Since we expose only the most important date and relationships in the entity interface, our interfaces are fairly stable. Adding a method every now and then is no big deal. --Victor =========================================================================== 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".
