Thanks everyone, I like the idea of using an IBO as this does bypass the expense of creating a potential huge array of 'employees' in my 'company' object. I've heard that transfer can do this for but I like to really understand how things work and why I should do it that way. Once I get it, I'll use Transfer or even hibernate to do it for me.
- John 2008/9/30 Peter Bell <[EMAIL PROTECTED]> > @Jon, > You don't have to, but personally I take the position that an IBO is a > collection of 0..* objects and that a single business object is simply a > collection where n=1. The key for me is that if I have a custom getter like > User.getAge(), I might want to display the age of either a single user or of > a list of users and I don't want to repeat myself, so the same code needs to > be available for both a single business object or a collection of them. My > simple work around is just to use business objects that extend a BaseIBO for > both my single instances and my collections. I wouldn't say it is incredibly > elegant conceptually, but I haven't come across and practical problems > working this way in over 80 projects - they are clean, quick to build and > easy to maintain - even with lots of client back and forth, so it's working > for me. > > Best Wishes, > Peter > > > On Sep 29, 2008, at 4:51 PM, Jon wrote: > > I am also in the exact same boat as John is when it comes to OO and DB > layout. > I like the idea of an IBO to house my 1...* relationships, but would you > use the IBO in place of a bean for single instances? > > Thanks, > > Jon > > On Mon, Sep 29, 2008 at 12:00 PM, Brian Kotek <[EMAIL PROTECTED]> wrote: > >> You can also look at something like Transfer, which manages these kinds of >> relationships for you and caches the CFC instances to mostly remove the >> performance hit caused by creating lots of instances on each request. >> >> >> On Mon, Sep 29, 2008 at 6:51 AM, John Whish <[EMAIL PROTECTED]>wrote: >> >>> Coming from a database orientated background I've always thought of >>> relationships between two objects in the same way. If I have a company >>> object and an employee object then the employee object would hold a >>> reference to the company object. Recently I wanted to get a list of >>> employees for the company and it got me thinking that instead of looking up >>> to the database, maybe I should be holding an array of employees in the >>> company object. This has some advantages, but seems like a bad idea. Has >>> anyone actually done it like this? >>> >>> Thanks in advance :-) >>> >>> >>> >> >> >> > > > > > > > > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "CFCDev" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/cfcdev?hl=en -~----------~----~----~----~------~----~------~--~---
