Hi Jon. I think the Employee IBO has a Company IBO but of course neither need to be IBO's if you're displaying details for one employee and they only have one company associated with them. If you don't need to display the company details at all then you may decide to ignore the company altogether.
If its a list of Employee's then an Employee IBO and an associated Company would do. I accept Peter's point that for consistency why not ALWAYS make the business objects IBO's but I wanted to make the point for the Employee -> Company relationship, Company would never need to be an IBO as long as the employee has only one company associated to them. So in your Employee object you would have 'variables.Company' containing a reference to the Company object and could use 'Employee.getCompany().getName()' to get the company name. If you think you may change the implementation of the Employee / Company relationship you may want to put delegate methods in Employee to encapsulate this decision and also make the calling code more readable ie 'Employee.getCompanyName()' ( and in Employee you would have a delegate method 'getCompanyName()' that simply called 'variables.Company.getName()' ) ----- Original Message ---- From: Jon <[EMAIL PROTECTED]> To: [email protected] Sent: Tuesday, September 30, 2008 8:02:40 PM Subject: [CFCDEV] Re: one-to-many relationships 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 -~----------~----~----~----~------~----~------~--~---
