Yet another gentle reminder of a lesson I've learned the hard way: I put too much behavior in our original Entity Bean design, rather than decoupling it to Session Beans. In addition, we have a lot of relationships in the Entity Interfaces. We had no experience to guide us. Now that hindsight is clear, any new design would make the Entities a lot more like "dumb data" and the Session Beans a lot more like real use cases.
As it is, we have a few extremely general Session Beans which tend to be omnipotent (use a lot of reflection) and Entity Beans which tend to be too smart (calling a setter method on an Entity attribute may trigger additional business logic). The weakness in this design is obvious when we begin to think about minor changes from client to client: the omnipotent Session Beans need to give special treatment to certain clients, and the too-smart Entities need to be "retrained". On Thu, 24 Oct 2002 10:14:34 -0400, Victor Langelo <[EMAIL PROTECTED]> wrote: >> * 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".
