Time to Rethink the (Table Data) Gateway?

I have already argued that that encapsulating property access using an IBO makes sense whether you are returning one record or many. But in this post I wanted to look at some of the other outstanding questions I had about Gateways, to look at some non-CF references and to ask whether anyone could shed some light on how we ended up with this “convention” in the CF world.

The first question you have to answer when deciding to use Gateways is what exactly they should include. I’ve put together some possible ways of distinguishing what goes into a Gateway below using the examples of whether they should only be used for “get” methods, whether they should be used for all “filter” based methods or whether they should be used for all methods operating on more than one record.

Get Only
One approach to gateways is to use them to handle all “get” methods that could return more than one record – and nothing else. With this approach, getbyUserbyIDList(“3,4,7”), getList(“where Price > 12”) and getUserSignupReport(“01/02/2005”,”01/02/2006”) are all example of methods you might call against your gateway.

All Filter Methods
Of course, all SQL queries are based on some kind of “where” filter (except for a getAll() method), but I am using “filter method” to describe a method that is designed to return a fundamentally indeterminate number of records (orders so far this year, number of users who are between 20 and 25, number of products for under $100, etc.).

I am contrasting that with methods that are designed to return a known number of records or 1/0 records per requested value. Examples of methods that would NOT be included in the Gateway would be delete users 23 and 41, get product where SKU is ARA3112 or get user where email = test@test.com (assuming product SKU and user email are defined/constrained as unique attributes that will only ever return 0 or 1 record per value in your particular application).

So, with all filter methods in a gateway it might have methods like deleteAbandonedCarts(), getAllUsers(), and getCheapProducts(“$50”).

All Multi-Record Methods
In this case, gateways would handle everything except for a single record create, read, update and delete. So saveProductPrices(ProductCollection) and getUserbyIDList(“7,3”) would be added to all of the methods in the “all filter methods” approach (unless you used an iterator in the service layer to save and/or get every record one at a time making multiple calls against the DAO – could make sense for saves in some use cases).

I would be interested to hear how people handle saving multiple records, deleting based on filters, inserting multiple records and the other methods that could be argued either way to see how strong the consensus is for exactly what should go in a gateway.

History
Martin Fowler explored the the (Table Data) Gateway in his Patters of Enterprise Architecture book (a summary of the patterns is available online). In his reference architecture the Gateway handles ALL database interactions (replacing the DAO) and is referenced directly from the business object (not a service layer).

If you look at the core J2EE patterns, DAOyou will see that the intent of the DAO there seems very similar to the intent of Fowlers Gateway pattern. The most obvious distinction is that the DAO explicitly uses a transfer object to interact with the business object whereas it isn’t clear what parameters/data types a Gateway uses to interact with a business object.

Some time ago there was an interesting articlecomparing the two approaches. I think the original author was right that the two patterns are fundamentally similar and that the main difference is that Fowlers Gateway is simply less prescriptive about the method signatures. The only definitive difference is that a DAO should use a transfer object whereas it is not clear whether a Gateway should or not.

I actually like active record patterns. Why should a business object use a transfer object (especially in CF where object instantiation is not inexpensive) when it can simply pass itself to the DAO to work with directly? The biggest benefit of a TO is that it will usually have just the properties that need to be saved and no others, allowing the DAO to know which properties to persist, but a fairly simple explicit metadata convention can get you the same benefits without the additional object I may start to use TOs here down the line, but for now I find them to be overkill for my needs (and I notice that most CF apps I see don’t use TO’s between the business object and DAO but rather pass the business object via the service layer AS a transfer object).

It seems to me that at some point, someone latched onto the distinction between a DAO and a Gateway as whether get operations returned an object (DAO) or maybe didn’t (Gateway). I don’t think there is anything wrong with such an approach (apart from the fact that you now have your naked recordsets running round the application with no way to easily vary the getting of the properties other than through some kind of hacky loop I the service layer which doesn’t scale well in terms of maintainability for complex solutions). I do think it is time to revisit the Gateway to see if it is really as useful as its current ubiquity in the CF world would suggest.

What do you think?