Andrew's ramblings

more ColdFusion 9 and ORM goodness

Tags: Coldfusion, CFORM

In my last post I gave you a very quick introduction on how to get started with ORM in ColdFusion 9, in this post I am going to give you a look at some of its power that will make you think twice about using cfquery again.

There are times when we create a table we sometimes have to stop and think about the relationship between two or more tables, do we create them as one table or do we create them as 2 or more tables. And more importantly how does that then impact me on my coding, and can I identify in my code what I am actually trying to do with a quick glance at the code.

The short answer prior to ColdFusion 9 this was difficult at its best. So to illustrate a simple yet very powerful part of CF-ORM lets have a look at a userAccount written in CF-ORM that can be either defined as a Consultant or and Agent.

I chose a Consultant and an Agent due a previous application I wrote, there was 2 difference to these 2 types of account logins and yet they were also very similar.

So lets look at the parts that are similar first. The following is a component called userAccount.cfc

So what we have here is a persistent component, or what we shall call a Domain Class. This Domain Class as you can see has the most basic information such as username, password, and whether it is enabled or not and a few others.

Now what we are going to do is had one more thing to the above code, and change it to look look the following.

At this point this extra information is telling CF-ORM that we are going to have a column that can be used as a discriminator, which will be explained a little bit later.

So lets create another component for an Agent, and one for a Consultant. Lets do the Agent first.

As you can see we have create another component with a few extra attributes to the component, the first is that we are going to extend the userAccount and the next is we are going to join them with the primary unique field username. And that the value of the disciminator will be Agent.

Now for the Consultant component.

So what do we have here, what we have is 3 tables that are actually linked. Linked in what way you might ask. Ok CF-ORM uses something called a discriminator, this is a way to to link the components together in a few different ways. The fact that we have a discriminator value on the Agent and Consultant might not be too obvious to you at the moment. But consider the following code example.

When creating a new account we have two options available to us now, which is illustrated as such.

You might be wondering yeah, but you said they were linked. Well if we were to dump one of these objects out to the browser you will notice something unusual. They both have similar properties, which is were the userAccount comes in and why I mentioned that these would be using parts that are similar.

Ok but that's not that magical I might hear you say.

Ok try populating some of the fields with the setters that are automatically given to us. And the saving the object out.

This will now save the objects back to the database and perform something else under the hood. Warning I have some values that are required, so you might wish to add them to the object with their respective setters before saving.

Now lets load a user

If you were to now run the above code and load the user, you will notice that it will have loaded the Agent information. The same would apply if you changed the above code to load user2, would load the consultant object.

This is just the beginning of the power of CF-ORM, but if you have done these sort of applications you can begin to see how these objects make working with ColdFusion 9 far easier than ever before.