Cameron, I tend to develop the way you're describing as well, but here's how I figure Transfer into the mix... Okay, any service object is typically going to be a composite of underlying, simpler objects that DO have a 1 to 1 relationship to the db. For instance, if you are writing a "smart" userService cfc (service layer) that performs all kinds of tasks such as your user CRUD, authentication perhaps, calculating employee discounts, or who knows what, you must still at some point in the code interact with the user table and/or its related tables. Without an ORM, we do this with the sql in our queries, perhaps writing complex joins and the like in order to return the record sets we want, or by manually creating some dumber 1 to 1 objects. By tossing Transfer in the mix, however, what I have done is eliminate the need almost entirely to write any sql, to worry very much about handling transactions manually, and giving myself the ability to do some cool "magical" things like cascade deletes and saves. So, your transfer.xml file will define all of those one to one table relationships (not your smarter, more complex service layer objects), and then your smart CFCs will simply manipulate and utilize those Transfer objects in lieu of any SQL or hand written beans or other simple objects that you need. This is how I see it, anyway.
In addition, Transfer gives you the wonderful ability to still "write sql" when you want/need to, only in a slightly modified syntax called TQL. Leveraging this baby allows you to do anything you would in a query (pretty nearly anyway), plus giving you the ability to "store" a search without having to actually store the results or a lot of separate parameters; you generate TQL statement based on user criteria selections in your form, then store that TQL statement in your db for use later on. That's just one application for TQL that I have personally found and loved. Just my two cents. Doug Boude :0) On Mon, Jun 15, 2009 at 1:28 PM, Cameron Childress <camer...@gmail.com>wrote: > > So, I've been toying with Transfer off and on since CF.Objective, but > I think I've come to a end of my exploration. I wanted to ping the > like and make sure I'm not missing a solution here. > > I have an existing application I'm refactoring using ColdSpring and > wanted to use Transfer too. However - most DTOs in this application do > *not* have a 1-to-1 relationship to a table in the database. In fact, > I think most projects I work on don't have DTOs with a 1-to-1 > relationship to table in the DB (meaning user table = user.cfc). Alot > of DTOs are composed of several DB tables joined together to represent > a single DTO in the application. > > Transfer seems very well suited for applications which are designed to > have a single table pair up with each DTO, but very poorly suited for > applications where the DTOs are flat composites made from several DB > tables. > > I wanted to confirm the above statement(s) and make sure I hadn't just > misread the situation. > > -Cameron > > -- > Cameron Childress > Sumo Consulting Inc > http://www.sumoc.com > --- > cell: 678.637.5072 > aim: cameroncf > email: camer...@gmail.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 transfer-dev@googlegroups.com To unsubscribe from this group, send email to transfer-dev-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/transfer-dev?hl=en -~----------~----~----~----~------~----~------~--~---
