As usual, I agree with most of what Jared is saying, but I just wanted to provide another perspective.
It is true that you can use TQL/SQL in your Decorators and Services, and this will save you from creating an extra cfc, and an extra layer in your model, but I tend to put those into a Gateway. I try to encapsulate all of my database access into gateways, and I include talking to an ORM as database access. So most of my SQL, TQL and Transfer calls are actually in gateway classes. I just find this to be a nice separation of concerns, and will make things easier if I ever decide to change my method of database access. Realistically I doubt that I will be doing that (changing my ORM), but it is possible (maybe with CF9?) and is quite easy to plan for. So although I am creating an additional layer of abstraction, it doesn't necessarily mean I have to write a lot of extra code. I use an abstract gateway, which I extend in each of my concrete gateways, so a lot of those concrete gateways have very little code in them. Also, I do not create one gateway per business object, rather I create one gateway per service. So in an app with, say, 50 business objects, I might have just 10 services and gateways. So again, let me just state that I do not disagree with Jared's approach, and I totally understand why some would see it as more practical. I just choose to do it a bit differently and I thought maybe folks would be interested to hear why. One last note: As indicated above I have changed things a bit from the way I was doing them when I wrote my "How I Use Transfer" series of blog postings. I plan to write another posting or two in the near future which will introduce some of the changes, most of which are based on this concept of always using a gateway to interact with Transfer. Cheers, Bob On Tue, Nov 11, 2008 at 1:08 PM, Jared Rypka-Hauer <[EMAIL PROTECTED]> wrote: > > Keep in mind that Transfer has it's own variety of CFCs that it loads > up, but it features things like an uber-cool caching mechanism, so > overall your app should indeed load faster and run better using > Transfer. Another nifty thing that comes with Transfer is the > JavaLoader that you can use to load ad-hoc jar files into your > ColdFusion application without having to deploy them to CF and > restart the server... so it's cool on several fronts. > > It sounds like you're headed in the right direction... keep in touch > with the list as you move forward, I'm sure you'll have many more > questions as time goes on. ;) > > Jared > > > ------------------------------------------------ > Jared C. Rypka-Hauer > Senior Software Engineer > Alagad - http://www.alagad.com/ > > Member: Adobe Community Experts - ColdFusion > Certified Advanced ColdFusion Developer > > On Nov 11, 2008, at 11:56 AM, Jorge Loyo wrote: > >> J, >> >> "We're pretty much working with the philosophy that Transfer is a >> parallel to the DAO/Gateway concept" >> >> This is what I was thinking because as of now, in my current >> application I have over 160 CFCs (Gateways/DAOs) that could be >> eliminated if I can use Transfer to replace that functionality (most >> cases).... I am assuming this would drastically increase the >> application load time as well.. Is my assumption correct? >> >> So thank you again, and yeah... the transition is slow, but I know in >> the long run it'll payoff. > > > > -- Bob Silverberg www.silverwareconsulting.com --~--~---------~--~----~------------~-------~--~----~ Before posting questions to the group please read: http://groups.google.com/group/transfer-dev/web/how-to-ask-support-questions-on-transfer You received this message because you are subscribed to the Google Groups "transfer-dev" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/transfer-dev?hl=en -~----------~----~----~----~------~----~------~--~---
