Elliott, I totally understand what you mean and you're right on with the car/ gas can analogy. I know I'm wasting a bunch of functionality and if I, or another developer, were to call just about any other method on this object other than a getter/setter/decorator method, I'd get a nasty error.
All, What I'm trying to get at is, how do you rectify the two different objects. We all know now the solution I came up with but what strategy do you use? As it stands right now my Transfer object also has at its disposal a validate method, added in the decorator, and an ErrorCollection that it can use to store all validation errors. I need all this functionality but don't want to have to maintain two very different ways of creating/using objects. Mark, This is really your baby. haha. Am I totally bastardizing everything it stands for? ;-) John On Nov 19, 3:03 pm, Elliott Sprehn <[EMAIL PROTECTED]> wrote: > 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 -~----------~----~----~----~------~----~------~--~---
