Bob's Blog

I left something critical out of my last post about how I'm using Transfer (an ORM for ColdFusion) these days.

If you've been following along you'll know that I'm using an Abstract Transfer Decorator, which all of my concrete decorators extend, and that I'm using Brian Kotek's most excellent Bean Injector to load singletons into my Transfer objects. This raises an interesting issue: How to inject the appropriate Gateway Object into my Transfer Object.

[More]

I've been meaning to follow up on my How I Use Transfer series, as I've made a few changes to the way I write my ColdFusion code since that series was written. One of the biggest changes was to encapsulate all database access in my Gateway components.

Now I say biggest not because it took a lot of time and effort to make the change, in fact the opposite is true. I say biggest simply because it represented a significant shift in the way I'm designing my model. Let me start with the rationale for making this change.

[More]

In the previous post in this series about Transfer (an ORM for ColdFusion) I discussed the populate() method of my AbstractTransferDecorator. Having discussed some of the simple methods of this object in the post prior to that, what remains is a discussion of how I'm currently using this object to do validations.

There are three methods in this object that are used to support validations in my apps:

• getValidations() - This returns an array of business rules that apply to the Business Object.
• addValidation() - This is a helper method to make defining validations simpler.
• validate() - This contains generic validation routines that are shared by all Business Objects.

Let's start with getValidations(), which returns an array of business rules. This array does not include any information about implementing those rules, it simply describes the rule, and any requirements for the rule. For example, one rule might be Required, which simply means that the user must enter a value for the property. Another rule might be Range, in which case the array item would also include the upper and lower limits of the range. One of the nice things about this approach is that this array can be used to generate both client side and server side validations. So I only have to describe the validations for a given object once in my app, and then I have additional pieces of code which take these rules and automatically generate the JavaScript required for client validations, and the CF code required for server side validations. We'll see an example of the latter when we discuss the validate() method later in this post.

[More]

In the previous post in this series about Transfer (an ORM for ColdFusion) I introduced my AbstractTransferDecorator and discussed some of its simpler methods. In this post I want to go through the populate() method in detail. I have posted bits and pieces of this method in the past, but I don't think I've ever documented the whole thing, as it stands today. I'll break it into pieces to make it a bit more manageable.

[More]

In the past two posts in this series about Transfer (an ORM for ColdFusion) I discussed how I have implemented my Abstract and Concrete Gateways. As you may recall from Part II, that leaves my AbstractTransferDecorator Object as the final abstract object in my model. There is a lot of code in this object, and I plan to provide a lot of explanation, so I'm going to break this up into a few posts.

My AbstractTransferDecorator acts as a base object for all of my Concrete Decorators, and, because most of my Business Objects are created for me by Transfer, it really acts as an Abstract Business Object. For a basic overview of what a decorator is, and how one is used with Transfer, check out this page from the Transfer docs.

I have blogged about this object a few times before, but the posts in this series will, for now, supercede all of those previous posts, as this object continues to change. In fact, this object has a few methods and techniques the design of which I'm not crazy about right now. There will definitely be changes coming, at some point down the road.

[More]

In the previous post, I described my Abstract Gateway Object. As I did with the Service Objects, I'm going to take a moment to describe a Concrete Gateway Object as an illustration of how I use the Abstract Gateway. I'll start with a recap of the differences between the Abstract Gateway and Concrete Gateways, followed by a look at the code of a specific Concrete Gateway.

• The Abstract Gateway Object
• Is never instantiated as an object.
• Cannot be used as is.
• Is only ever used as a base object for Concrete Gateway Objects.
• There is only one Abstract Gateway Object, called AbstractGateway.cfc.
• Does not have any Transfer classes associated with it.

• Concrete Gateway Objects
• Are instantiated as objects.
• Methods on them are called by Service Objects.
• All extend AbstractGateway.cfc.
• There are many Concrete Gateway Objects, e.g., UserGateway.cfc, ProductGateway.cfc, ReviewGateway.cfc, etc.
• Have one "main" Transfer class associated with them, but can interact with others via code specific to the Concrete Gateway.

One thing to note here is that my Gateway Objects are all injected into Service Objects via Coldspring, and are only called by Service Objects. So the Service acts as an API to the entire model. If a Business Object needs to call a method on a gateway, it calls it via a Service Object that is injected into the Business Object.

[More]