http://www.objectorientedcoldfusion.org/wiki/Gateway#Minimising_duplication

I combine methods for getting single and multiple records into one CFC. Furthermore, my single getter calls the multiple getter and thru-passes the ‘id’ argument. There are conditions inside the multiple getter to specify a WHERE clause if the argument is passed. This means that you just have a SINGLE query rather than one for each purpose.

In terms of returning data, I tend to lean towards returning a struct or an array of structs. I find it tends to make things a little easier in use. It also means I can add sub-structures to the result. (e.g. if I want a user record, I can add the info about the user type to the record. You can’t do that in a query).

I use a conversion CFC that I put together to go from query to struct (or array of structs).

Just goes to prove that there are LOADS of different ways to do things in ColdFusion
–
Mike

Good luck with Reactor. And keep in mind that you have Transfer available as well (http://www.transfer-orm.com).

It would appear that Reactor is not getting much attention these days. Some important bugs remain unfixed even though patches have been submitted many months ago, and the Trac site has quite a bit of spam that is not being cleaned up

But I would be happy to know that I am wrong about this assumption!

I don’t see the benefit of using an array of structs over a query though – is it to do with flexibility of data types?. At the moment, the component just uses the query and stores a pointer to the current row and the whole thing is about 50 lines of code so is very unbloated. It could be even less so because I think there should be a plain iterator base class and a BOI should inherit from that.

I’ve just installed reactor so I’m very interested to see what they do with their iterator (I saw the words GetIterator() somewhere and got excited, oh dear).

D

Great idea. This has some similarities with Peter Bells "Iterating Business Object" idea (http://www.pbell.com/index.cfm/2007/8/13/IBO-Sample-Code and the big brother version http://www.pbell.com/index.cfm/2007/6/20/IBO-20–Return-of-the-Iterating-Business-Object-Now-on-RIAForge)

The essence of Peter’s idea is something along the lines of:

o_myIBO = myDAO.read(args)
while (o_myIBO.next()) {
o_myIBO.methodThatActsOnTheCurrentRow();
}

Initially I wasn’t convinced that this was such a good idea, but thinking it through more I believe that it is particularly suited to ColdFusion development, primarily due to the potential performance gains, so makes it a good option for iteration.

Incidentally, I understand that the best performance gains are provided when converting the query result to an array of structs inside the IBO (or DAO in your case) and maintaining a pointer to the "current" struct in the array.

Thanks for your thoughts.

I have just created an iterator base class, that, with very little code under the hood will let you do like this:

o_myDAO.read(args); // depending on the args will get different result sets
while(o_myDAO.next()){
o_myDAO.methodThatActsOnTheCurrentRow();
}

I think the tricky part is keeping the create, update and delete methods un-muddy but I think you could still do this AND have a seperate Gateway component for CUDding.

My temporary conclusion is that the iterator is useful in situations where you would need a seperate instance of an object for each record returned from a query but that this does not replace the ‘need’ for a Gateway object.

Dom

However, it did seem nice syntax to have code like

<cfset person.save()>
<cfset postcode = person.getStreetAddress().getState()>

where the ‘person’ is my bean loaded up DAO and Gateway artillery. But I am trying some alternatives now.

I gave Reactor a run ( http://trac.reactorframework.com ) which also uses the Active Record pattern. This combines business objects with the data layer.

I am now looking into Transfer ( http://transfer.riaforge.org ) instead which separates out the business objects and the data layer.

Sean wrote up a comparison of the two:
http://corfield.org/blog/index.cfm/do/blog.entry/entry/Comparing_Transfer_and_Reactor

I believe that generic get() and set() functions have special case uses rather than in common application beans. Peter Bell ( http://pbell.com) uses them in his application generator (they are not hand coded) and I would favour using them whenever an object has a range of general name/value properties.

For the general approach I would still favour the setName()/getName() style. If typing all of those get and set statements is a problem, then Transfer or Reactor or something like Brian Rinaldi’s CFCGenerator ( http://code.google.com/p/cfcgenerator ) might be just the ticket.

Eventually, I read about this thing called a gateway object in cf and that seemed like it would be a good way to get rid of the door/house problem, so I put that in place. The gateway would return either arrays of objects or recordsets as requested. There was no direct coupling from the bean’s point of view. Any beans necessary would be instantiated in the gateway. That seemed pretty good for a while.

After a while, I started feeling that the little CRUD wrappers I had in my beans to facilitate the use of the DAO started to feel strange to me. I would look at those methods and think "they have nothing to do with my business logic and add a lot of noise to my bean code". So, I reworked things again. Now, my beans are completely ignorant of storage mechanisms. Instead of instantiating the DAO with the bean init function, I now pass in the bean to a separately created DAO. It adds a little more code to the software that uses the objects, but you feel a little more in control. You only need to deal with a DAO when you have to deal with your persistence technology.

Lastly, I noticed that now my DAOs and my Gateways where constructed in very similar manners. It felt like I had little reason for keeping them as separate objects. They pretty much do the same job – interact with my database. So, I put them both together. I now only use DAOs. The only reason I chose to use the DAO term instead of the Gateway term is that it just seems a little more descriptive and it’s easier to type.

So, that’s my trip. I basically ended up with what I started with, although they are built substantially different. I pretty much like the way they work now. Next for me is to look a little closer at the work Sean Corfield has done to create default get/set functions. That will certainly remove a lot of clutter.

Whenever apparent ‘rules’ present themselves it is easier to jump on board and use them rather than question them. And in the absence of experience or a guide it is as good a place to start as any.

Overall though, I think the best idea to read out of the DAO and Gateway concepts is to separate out and encapsulate data access.

The whole DAO/Gateway as separate CFCs thing dates back to a casual recommendation I made back in 2003 in the Mach-II Development Guide (on livedocs.adobe.com) when I was trying to help people structure their CFCs (when everyone was new to CFCs).

I hadn’t intended it to become a rule cast in stone but unfortunately that’s what happened.

I certainly don’t advocate this separation as a default these days – in fact I tend to put everything in a XyzGateway.cfc (although my single object persistence is usually handled by Transfer ORM these days).

I’ve constantly been surprised at how literally people have followed some of my old, old advice…