The dependencies exist, always... all an ORM does is handle the heavy
lifting of managing the interdependencies for you.
As for having to create instances of all those objects, lazy loading
would probably be the soluion for you. That is to say that when you
create a User, don't create the company then. Have your getCompany()
method say something like:
<cfif not structKeyExists(variables,"company")>
<cfset variables.company = application.companyService.getCompany
(getCompanyId())>
<!---
alternatively, use variables.ObjectFactory and always get your
objects thru ObjectFactory (including User) so that you have a place
to manage the injection of at least the factory into your
objects:
<cfset variables.company = variables.ObjectFactory.getObject
("company",getCompanyId()>
--->
</cfif>
<cfreturn variables.company />
That way you don't have to create the company when you create the
user but the relationships are still handled correctly. The only
issue you have at that point is creating your object factory to
handle the injection of your factory itself (and any other sort of
required objects) into the objects as you create them.
Does that help?
Laterz,
J
On Oct 1, 2008, at 12:05 PM, Jon wrote:
> Yeah I had looked into several of the ORMs everyone has mentioned,
> and others I had no idea about. I don't think "use a Framework"
> was the solution I was looking for though. This gives me a great
> tool to fix the issue of dealing with object relationships, but it
> doesn't necessarily tell me how to handle the relationship itself.
> I am sure I will use an ORM at some point, but I think it would be
> foolish for me to use a tool that fixes a problem that I don't yet
> understand.
>
> I really want to understand the actual problem that these
> frameworks solve before I actually start using them to solve that
> problem. I think Alan response gave me what I was looking for.
>
> If I have 2 Objects, Company (parent, PK) & Employee (Child, FK)
> each would have a property with the other in it?
>
>
>
> Company.getEmployees() - Retrieves a collection of employees from
> the employeeIBO that is stored in the Company Instance. This could
> be used to create an Employee Object (single instance IBO) for code
> purposes
> Employee.getCompany().getName() - Retrieves the Name of the Company
> that the Employee Belongs to from the company object that is stored
> in the Employee Instance.
>
> I assume this is the way to create those relationships?
> So when I create an Employee instance, I will also have to create a
> company instance to store in that Employee instance?
> The real value with an ORM would be when you have lots of objects
> with their tangled web of relationships. (ie Address object related
> to both Employee and Company)
>
>
>
> On Wed, Oct 1, 2008 at 10:46 AM, Jared Rypka-Hauer
> <[EMAIL PROTECTED]> wrote:
> And don't forget ObjectBreeze by Nic Tunney:
>
> http://www.nictunney.com/index.cfm?mode=cat&catid=D029AD0A-
> B7EA-0C18-465CB666C649835D
>
> Lightweight and "different" it's very generic approach makes dev
> fast but ongoing support a little less easy than Transfer or Reactor.
>
> Laterz,
> J
>
> On Oct 1, 2008, at 10:33 AM, John Whish wrote:
>
>> As Yoda would say "There is another"...
>> http://www.datafaucet.com/
>>
>> 2008/10/1 Tom Chiverton <[EMAIL PROTECTED]>
>>
>> On Wednesday 01 Oct 2008, Peter Bell wrote:
>> > 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.
>>
>> Obligatory mention of Reactor, the 'other' ColdFusion ORM :-)
>
>
>
>
> >
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
