Bob's Blog - ColdFusion Tidbits - How I Use Transfer

How I Use Transfer Today - A Gateway MapFactoryBean

Mon, 24 Nov 2008 16:33:00 -0400

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]

How I Use Transfer Today - Encapsulating Database Access

Wed, 12 Nov 2008 10:59:00 -0400

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]

How I Use Transfer - Part X - My Abstract Transfer Decorator Object - Validations

Sun, 27 Jul 2008 04:49:00 -0400

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]

How I Use Transfer - Part IX - My Abstract Transfer Decorator Object - The Populate Method

Tue, 22 Jul 2008 10:44:00 -0400

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]

How I Use Transfer - Part VIII - My Abstract Transfer Decorator Object - Simple Methods

Mon, 21 Jul 2008 12:11:00 -0400

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]

How I Use Transfer - Part VII - A Concrete Gateway Object

Tue, 15 Jul 2008 13:27:00 -0400

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]

How I Use Transfer - Part VI - My Abstract Gateway Object

Mon, 14 Jul 2008 06:35:00 -0400

In the past few posts in the series I discussed, at length, how I have implemented my service layer, which consists of an Abstract Service Object and Concrete Service Objects. I decided to take it easy this time around and just look at my AbstractGateway Object, as it's pretty simple in comparison.

As with the AbstractService, this object is not meant to be instantiated on its own, but rather acts as a base object which my concrete Gateway Objects extend. There are only three public methods in my AbstractGateway:

GetList(), which returns a listing for the default entity
GetActiveList(), which returns a listing for the default entity, but only includes Active records
ReInitActiveList(), which is used to reinitialize the cached query for the Active List (see below for details)

[More]

How I Use Transfer - Part V.1 - A Comment and Response

Tue, 08 Jul 2008 10:28:00 -0400

Brain Kotek wrote a lengthy and informative comment to my last blog post. I started composing a response as a comment of my own, but it got very long, and I think that both Brian's comment and my response contribute greatly to the series, so I've turned my response into a blog post. I'm including Brian's comments in quotes throughout this post.

[More]

How I Use Transfer - Part V - A Concrete Service Object

Tue, 08 Jul 2008 07:15:00 -0400

I was going to describe my Abstract Gateway Object in this post, but during a conversation with a fellow developer it was suggested that I should take a moment to describe a Concrete Service Object, as there was still a bit of confusion in his mind about how I use the Abstract Service Object.

To recap a bit, I have an Abstract Service Object and it is used as an extension point for most of my Concrete Service Objects. Perhaps a bit more of a definition is in order.

The Abstract Service Object

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

Concrete Service Objects

Are instantiated as objects.
Methods on them are called by Controllers, other Concrete Service Objects and Business Objects.
Most extend AbstractService.cfc.
There are many Concrete Service Objects, e.g., UserService.cfc, ProductService.cfc, ReviewService.cfc, etc.
Have one "main" Transfer class associated with them, but can interact with others via code specific to the Concrete Service.

[More]

How I Use Transfer - Part IV - My Abstract Service Object

Thu, 03 Jul 2008 11:11:00 -0400

In the previous post in the series I discussed how I base most of my objects on Abstract Objects, which allows me to eliminate a lot of duplicate code. I then took a look at one method in my AbstractService object to demonstrate this. In this post I'm going to look at the rest of the methods in the AbstractService, so be prepared for a lot of code.

Let's start with the Init() method and the Configure() method:

[More]

How I Use Transfer - Part III - Abstract Objects

Mon, 30 Jun 2008 10:39:00 -0400

In the previous post in the series I discussed the four types of objects that comprise my model. As I was creating instances of those object types I realized that they did a lot of the same things. For example, my UserService needed methods like getUser(), updateUser(), deleteUser() and listUsers(), while my ProductService needed getProduct(), updateProduct(), deleteProduct() and listProducts(). Not only do they need to do similar things, but they pretty much do them the same way. Now that's a lot of code duplication.

So I created an AbstractService, which each of my concrete Service Objects extend. My AbstractService has methods like Get(), Update(), Delete() and GetList(). For the most part, the code required for getUser() is identical to the code required for getProduct(), with the only difference being the business objects with which they interact (User and Product, respectively), so I was able to write a single, parameterized method, which will work for most of my Service Objects.

[More]

How I Use Transfer - Part II - Model Architecture

Tue, 24 Jun 2008 06:36:00 -0400

I think that the best place to start is with the high level architecture of my model. I have four types of objects in my model:

Service Objects
Gateway Objects
Business Objects
Utility Objects

Note that these names are not necessarily the generally accepted or "proper" names for these types of objects in the Object Oriented community. These are terms that I have chosen to use, and I will define what I mean by them.

[More]

How I Use Transfer - Part I - Introduction

Mon, 23 Jun 2008 08:24:00 -0400

I've now been using Transfer for about a year, and I've built up a bit of a standard way that I use it in my apps. I'm not suggesting that this is the best way (by any means), but I thought it would be worth posting about it to share my experiences and learn from others. So I'm starting a new series, simply called "How I Use Transfer".

I'm not sure how to best go about describing all that I do. A lot of it is really architectural and isn't specific to Transfer. To a certain extent Transfer could be switched out for another ORM without requiring a lot of code changes. So I suppose this is also about my approach to OO design with ColdFusion. Like others, I have found this to be a long and hard learning curve, and I still have a long way to go. It may be that much of what I'm about to document will change over the next several months, as I learn other ways of doing things, but hopefully it will still be of value, particularly to anyone just starting down this road.

So again, I'm not trying to document any kind of best practices. I already know that there are ideas I've read on other people's blogs that I'd like to implement but haven't yet. This is a snapshot, a point in time, something I'll probably revisit months or years from now and laugh about. But if others are going through the same thing as me, then maybe we can all learn together.

In my next post I intend to describe a high level overview of the architecture of my model.