Most ORM's will handle your object relationships so they will load
your employees into your company object and so on. Check out Transfer
and Hibernate.
Best Wishes,
Peter
On Sep 30, 2008, at 10:01 PM, Jon wrote:
> Sorry, but I guess I don't follow, I thought ORM's were there to map
> the Domain Objects to the Database tables? This is not my issue, I
> could be horribly off as I am still a complete noob to alot of this.
> =)
>
> In my database I handle both sides of a relationship with a primary
> key/foreign key combination which takes care of both sides of the
> relationship (parent/child).
>
> I am trying to understand how this is done on my objects by making
> the parent object a property of the child object sort of like a
> foreign key in database terms. as opposed to just storing the ID
> property of the parent object as a property in the child object.
>
> I think I have my head wrapped around that, but what is a good
> course of action when you have an object that could be a child to
> more than 1 parent?
>
> For instance, I have the following Object
> Address Object
> Company Object
> Employee Object
>
> Both Company and Employee Objects could contain an Address Object,
> and both could contain more than one (Home Address, Work Address,
> Corp Location, Store Location 1, Store Location 2)
>
> Now I would build out my database with 5 tables
>
> Company table
> Employee Table
> Address Table
> EmployeeAddress Table (contains only FK's)
> CompanyAddress Table (contains only FK's)
>
> ORM would map the 3 objects to the 5 tables and handle any CRUD if
> my assumption is correct, but how does this handle my Object
> Relationships? Can I assume this is where something like coldspring
> would come in? or is this also built into transfer.
>
> I know I am probably making things much more difficult than it needs
> to be and I do plan to attack both coldspring and transfer, but I
> want to learn the manual way first so I can truely appreciate and
> see the value of these two frameworks. I really appreciate
> everyone's responses and help!!
>
> On Tue, Sep 30, 2008 at 4:57 PM, Peter Bell <[EMAIL PROTECTED]>
> wrote:
> Personally, I explicitly lazy load all relationships. My BaseIBO has
> a getAssociated() method which loads up some metadata expressed in
> XML that describes the object relationships and then uses that to
> call the appropriate service class for the associated object which
> in turn returns the IBO of the associated object(s).
>
> So a page might look like:
>
> #Category.getTitle()#<br />
>
> <cfset ProductList = Category.getAssociated("Products")>
>
> <cfloop condition="#ProductList.next()#">
> #ProductList.get("Title")#<br />
> </cfloop>
>
> Bear in mind, ORMs like transfer and hibernate were written to take
> care of all this stuff for you, so you might want to look into
> letting them manage the relationships . . . That said it isn't that
> hard to write up a simple ORM. In fact, I just wrote an article
> about how I wrote mine for the next edition of the Fusion Authority
> (plug plug!).
>
> Best Wishes,
> Peter
>
>
> On Sep 30, 2008, at 4:56 PM, Jon wrote:
>
>> Yeah, I figured if my Employee is going to be an IBO no matter what
>> as Peter recommended. I mean if it already exists as an IBO might
>> as well use it as a single instance. I usually code in the frame
>> of mind that if it can change, then it will probably will change in
>> the future so why not prepare for that chance now.
>>
>> The Company-->Employee example is obviously simplistic example
>> compared to what I am running into. This really starts to hit me
>> when your dealing with multiple relationships on a single object.
>> Things like a Company has both Employees and Clients, but an
>> Employee could have multiple clients that they manage. Then from
>> there things could drill down, a Client could have a location(s)
>> which could then have Services/Products that relate back to the
>> Company, but I am getting way OT now.
>>
>> I was just having issue with the fact for my DAO(TDG) I need the
>> ID's when manipulating the database, so I have to pass at them
>> around at minimum.
>>
>> When employeeService.save(employee), the CompanyID needs to be
>> stored somewhere in the employee to be placed in the employee DB
>> table (as a FK). And trying to stick with OO principles, since I
>> have the companyID, i really should already have the company object
>> so I might as well have the company object as a property of
>> Employee. I just wasn't sure if this was good practice or not.
>>
>>
>> On Tue, Sep 30, 2008 at 2:57 PM, Alan Livie <[EMAIL PROTECTED]>
>> wrote:
>> 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: cfcdev@googlegroups.com
>> 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 cfcdev@googlegroups.com
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
-~----------~----~----~----~------~----~------~--~---
