Bob's Blog

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.

Let's take a look at an example of a Concrete Gateway Object, ProductGateway.cfc. To start, here's the Bean definition of this gateway from my Coldspring config file:

In here I indicate that the main Transfer class with which this service interacts is product.product. That means that calls to GetList(), GetActiveList() and ReInitActiveList() will be directed at the table defined to Transfer as product.product. I can write additional methods in my gateway that will interact with other Transfer classes, but the default methods, inherited from the AbstractGateway, will be directed at product.product.

I also indicate that the property that represents the description of the main class is ProductCode. That is used as a default sort sequence for the default methods.

And here's what's inside ProductGateway.cfc:

Here I'm overriding the default GetList() method to allow for criteria to be passed in by a user. This function is based on one automatically generated for me by Brian Rinaldi's most excellent Illudium PU-36 Code Generator. One thing to note in here is the Transfer Class that this TQL is referring to. It's called product.catalog_admin, and is actually pointing at a view in my database. The product information in this application is spread across many tables, and rather than having to write a complicated TQL statement with multiple inner and outer joins, I just write my TQL against a view that already joins everything together.

Let's look at another method on the Concrete Gateway:

This is basically just another query that I need within the application. My Concrete Gateways are quite simple in that they only include methods that return query objects.

As I alluded to in a previous post, I have one "special" Concrete Gateway Object, called ValueListGateway, which I use to interact with all of my "code" or "lookup" objects. It is used for objects like UserGroup, OrderStatus, ProductCategory, Colour, etc. It too extends AbstractGateway, but is built itself in an abstract way so that I can use it to interact with all of those "code" objects, without having to write a Concrete Gateway Object for each one. I plan on discussing that in a future post.

In the next installment I'm going to start looking at my AbstractTransferDecorator, which can be thought of as an Abstract Business Object.