What worries me the most about about this idea is that it utterly breaks the insides of Transfer on a global scale. Essentially the entire public API that it provides won't work. That is, readByProperty () , readByPropertyMap(), TQL, saving, deleting, relationships... won't work. And it won't just fail silently, Transfer will throw nasty exceptions from the database.
This sounds like a nightmare for a new developer later maintaining your project when they look at the transfer.xml, try to call save on some object or some such, or try to understand why your code does what it does. What transfer does internally when you create objects is also very very complicated for simple objects. It makes a lot of sense for something that deals with the database (and the dynamic property/ decorator stuff), but for general objects? It's incredible overkill! I think you're much better off rolling your own management system for Objects, assuming you even need the kind of caching that transfer provides for your app. It's pretty trivial to generate objects based on an XML file, or just use plain old CFCs. Why would you even want the massive duplication between properties and the XML if it's not going in the database? :P To me, using Transfer like this really makes no sense at all. You've taken a car and used it as a gas can. Does it contain the gas for you and tell you much there is? Sure. Are you wasting 98% of what's provided? Yeah... On Nov 19, 1:26 pm, Jared Rypka-Hauer <[EMAIL PROTECTED]> wrote: > It depends on how you look at it, if ORM is object --> relational, > then it's no misuse at all, you're using Transfer as an object > factory to get your business objects and if they happen to have > persistence integration well that's cool. > > I'm glad I was wrong, FWIW, because this is cool. Sort of puts > another nail in the coffin of the notion that Transfer requires King > Database and puts the database before the object model. > > I'm going to try to write a sample application that goes thru the > process of setting up a Transfer-based app without using a service > layer at all, just real, behavior-laden domain objects... because > there's no reason that Transfer can't take the place of the service > layer and the persistence layer all at the same time. Should be > interesting. > > Laterz, > J > > On Nov 19, 2008, at 11:45 AM, Bob Silverberg wrote: > > > > > I like this idea. I can see how some might see it as a misuse of the > > ORM, but it seems like a very practical approach to me, and keeps > > things consistent (i.e., all Business Objects are Transfer Objects). > > > Thanks for sharing, > > Bob > > > On Wed, Nov 19, 2008 at 11:05 AM, John K. <[EMAIL PROTECTED]> > > wrote: > > >> I didn't mean to make anyone go out and code this up for me to see if > >> it worked, I was really just curious how others handled this problem. > >> Thanks for trying it out though Chris! ... --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
