I would strongly recommend that you do the upgrade, but it's may not be a trivial change for you, since Transfer has a particular API and a fairly rigid notion of database design. That said, it's flexible enough to cover most situations, just not all. One of people's biggest complaints is that Transfer doesn't have any support for one- to-one relationships, which seems to be a problem for some folks. And one of the nice things about Transfer is the fact that by using Decorators you can mirror your existing API so you don't have to change so much application code from the get-go.
And there are performance questions, especially if you're not on CF8, if you have many-to-many or one-to-many relationships with LOTS of related records. There can be a performance issue with pulling down 300 instances of the same object to reflect all the rows in the joined table. While Transfer is fantastic, and it does cover a large percentage of users, it's not a magic bullet and you need to get to know a bit about it and think about how it will work for or against you in your particular application. J On Oct 27, 2008, at 12:30 PM, Jorge Loyo wrote: > > thank you peter, > > Actually, the use of transfer would have eliminated the necessity of > creating about 159 CFCs... As you can imagine, the application load > time is pretty long. I may have some time soon to upgrade the app and > I want to see if including Transfer would be something I do. > > > > On Oct 27, 12:57 pm, Peter Bell <[EMAIL PROTECTED]> wrote: >> Just to jump in, firstly, for most cases, who cares? It'll work well >> enough and pay for itself in saved dev time (i.e. "what Jared said"). >> >> But guess what. Like anything else, your mileage may vary. If you use >> SP's or have unique edge case requirements, Transfer might end up >> being dog slow compared to hand optimized prepared statements. >> Probably quick and easy enough just to build it in transfer and then >> add custom sql if you profile the running app and find specific >> queries are causing you problems. >> >> Best Wishes, >> Peter >> >> On Oct 27, 2008, at 11:49 PM, Jared Rypka-Hauer wrote: >> >> >> >>> Unless you're going to roll your own in-memory caching system, >>> Transfer's going to bean a roll-your-own persistence tier any day. >> >>> To be honest, I haven't really looked at it just because the caching >>> layer and the time saved in development beat the crap out of >>> anything >>> I could do anyway. >> >>> J >> >>> On Oct 27, 2008, at 11:47 AM, Jorge Loyo wrote: >> >>>> What is the difference in performance between having my own DAOs, >>>> Gateways (with joins) and Beans and having transfer handle that >>>> part >>>> of my application?? >> >>>> Has anyone done any performance test that I could look into?? >> >>>> Thank you! > > --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
