Neil, Greg is right. If you are using J2EE, allowing the client to interrogate the entity beans is one of the biggest taboos. Session Facade and Value Object patterns are the way to go. And if you want to decouple your changing requirements Command, Batch Command and Factory patterns I described earlier can help too. ----- Original Message ----- From: "Greg Nudelman" <[EMAIL PROTECTED]> To: "JDJList" <[EMAIL PROTECTED]> Sent: Friday, May 10, 2002 2:07 PM Subject: [jdjlist] RE: Business Layer Instantiation
> Dear Neil, > > Forgive me if I oversimplify, but how about just writing a stateless > Session Bean, which would read the data from the db and pack it into a > collection of value objects? I think I read an IBM J2EE guideline somewhere > that said that if you think you'll ever need to retrieve more then 5-10 > business objects at once, the process becomes so inefficient (for reasons I > won't go into) as to make it impractical. I assume your expanded tree > retrieves >10 Entity EJBs. One way to do it then would be w/o Entity beans > at all, just session bean retrieving a >10 value objects. > > If you think you do still need Entity EJBs, the "Entity EJB Inherits Value > Object" pattern would be useful. If you need just 1 or 2 Entities, go ahead > and call them up individually, when the data comes back, it would be in the > form of a VO superclass. However, if you need a whole bunch of objects at > once, call you session bean and retrieve the data and pack them into Value > Objects instead, w/o the E-EJBs. > > I hope that helps, > > Greg > > -----Original Message----- > From: Neil Stevens [mailto:[EMAIL PROTECTED]] > Sent: Thursday, May 09, 2002 6:19 AM > To: JDJList > Subject: [jdjlist] Business Layer Instantiation > > > Dear List, > > I am designing a business layer that will be accessed by a number of > applications. > > By default I expect the model to instantiate objects on demand, accessing > the data layer as required. > > In Application A, a GUI tree is used to show part of the model. It starts > off collapsed, and the user opens up the branches that interest them. The > first time a node is expanded, it leads to a data access. If a node isn't > expanded, then the corresponding Business Object is not fully constructed. > This is fine. > > In Application B, a similar tree is used, but this time it starts of fully > expanded. There are several hundred leafs. This gives rise to dozens of > data accesses, which will be inefficient. I could write some code to do a > large query and construct the necessary Business Objects in one go. But how > does the Business Model know when to use which style of construction? > Should I pollute the Business Layer API with data access specific > parameters? > > I assume this type of problem will keep recurring, so I need a > flexible/extendable approach. > > Any ideas ? > > Neil > > > To change your membership options, refer to: > http://www.sys-con.com/java/list.cfm > > To change your membership options, refer to: > http://www.sys-con.com/java/list.cfm > To change your membership options, refer to: http://www.sys-con.com/java/list.cfm
