I have another question: I have a companyIBO and an employeeIBO. Now I physically store the companyID in the employeeID table of the database. In an effort to minimize thinking about the database from an OO perspective how would I store the relation from the employeeIBO? I understand the company object would have an employee property that holds the employeeIBO(1..*), but the other direction?
Would I just make the "companyID" a property of the employeeIBO? or Would I make a "company" property that holds the companyIBO in the employee object? My guess would be to give the "employee" object a "company" property that holds the companyIBO in it. I could also be overthinking this way too much and be way off ;) Hope this makes sense! Thanks, Jon On Tue, Sep 30, 2008 at 4:02 AM, John Whish <[EMAIL PROTECTED]>wrote: > 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 -~----------~----~----~----~------~----~------~--~---
