Re: [CFCDev] LTOs

[Pat Branley]

Correct me if im wrong here, but I was under the impression on smaller apps the Bean/Value object and the Transfer Object will converge. at its most simple both of these could be a struct, even the form scope. its totally up to developers then to enforce that values arent changed, and there is a very simple contract in place between the form and the DAO. ie. 'im going to give you a struct and your going to do some CRUD operation with it.' if you go to sophistication level 2. you then use a bean to model your form submit, so you create a cfc Bean.cfc with functions init() getX() setX() validate() at this level you pass the bean to the DAO and it just acts responsibly by only calling getX() for insert/update/delete and setX() for reads where it needs to. The bean is then acting as the trasfer object as you are using it to pass your data from the form (presentation layer) to DAO (data/model layer) Now you have a few contracts in place about what data the bean is modelling and what services other layers can expect. ie. 'if i call getX() im going to get this peice of data' I would categoriese peter's LTO at level 2.5. Theres a bean, and there is an LTO acting as a transfer object, but the TO doesnt quite give you that strict contract about the data being read-only. (because of using THIS scope. maybe getValue("valueName") would be more appropriate) At level 3 where yor bean and transfer objects are separated out, the form sets the values on the bean, calls validate() and then the controller is ready to save the data. So you create a transfer object and pass initialise it with validated data from your bean. you then pass the transfer object to 'transfer' your data from the controller layer to the model/data layer. Now you have a separate object to deal with objects in other layers. It cleanly separates the layers (or systems) so that changes are now more easily isolated and contracts between the layers are strict. Im not quite convinced that going from level 2 to level 3 realy gives you that much benefit ? I guess it depends on where the data goes once its in the bean, if 90% of the time its to a DAO for saving, then id say its overkill. Im just not really sure what other situations where it becomes usefull? i can see if you had large teams, it gives you clean separation, but does the overhead of maintaining this extra object make it worthwhile ? How large is a system where the designer of a bean/to/dao combo is not the same developer ? Pat Cliff Meyers wrote: I'll try to continue the discussion here so as to not hijack the other post :) What you both said makes perfect sense to me, and thank you for the extremely detailed explanations! I have to say that in my context (Mach-II user) that using TOs seems to make more sense than writing Beans. The BeanCreator is a useful tool, but the very fact that it had to be written to alleviate writing repetitive get/sets seems to indicate (IMHO) that maybe there's a better way of approaching this data transfer problem. The power of the bean (again IMHO) is in the validate() method that's specific to data being modeled by the bean. However I think that you could so something similar with TOs.. Why not just write what I'll call TransferObjectValidator classes instead? It has a single method, validate() that takes a TO as the lone argument. For each TOV that you write, just implement the custom validation logic needed for the particular type of data being modeled, and it just returns true or false as to whether or not the TO passes the validation rules being defined? At least to be, that seems to make more sense... we're bundling some generic set of data into a TO, and then asking whether or not the TO conforms to a particular set of rules. So instead of having 10 beans in an app with lots of set/get code and a validate() method each , we have a single TO and then 10 TOVs that implement the validation logic necessary for the TO to move "deeper" into the app where the business logic components actually start to do something with it. Maybe I'm missing something critical here since the sun is rising and I haven't been to bed yet :) At least to me, it seems like this technique would probably shrink the quantity of code written to deal with data transfer by a significant amount. Let me know what you guys think :) -Cliff On 5/8/05, Peter J. Farrell <[EMAIL PROTECTED]> wrote: Peter J. Farrell wrote: Beans (aka value object) and Transfer Objects (TOs) are all types of transfer objects. I've coined the term Lightweight Transfer Objects (LTOs) lately because not the a traditional TOs object as defined in the java docs, but almost sort of like an encapsulated transfer structure. Revision... LTOs use the THIS scope which is a public scope and can be modified outside of the CFC. LTOs are not fully encapsulated...but quasi-encapsulated as I hope the developer would refrain from changing the data inside the LTO after its' init(). Any changes to data should be done on a bean not on the LTO. LTOs are meant to be read-only. As you can see, I'm not a technical writer... -- Peter J. Farrell :: Maestro Publishing blog :: http://blog.maestropublishing.com email :: [EMAIL PROTECTED] Create boilerplate beans! Check out the Mach-II Bean Creator - free download. http://blog.maestropublishing.com/mach-ii_beaner.htm Not a computer nerd; merely a techno-weenie. -- ---------------------------------------------------------- You are subscribed to cfcdev. To unsubscribe, send an email to cfcdev@cfczone.org with the words 'unsubscribe cfcdev' as the subject of the email. CFCDev is run by CFCZone (www.cfczone.org) and supported by CFXHosting (www.cfxhosting.com). CFCDev is supported by New Atlanta, makers of BlueDragon http://www.newatlanta.com/products/bluedragon/index.cfm An archive of the CFCDev list is available at www.mail-archive.com/cfcdev@cfczone.org ---------------------------------------------------------- You are subscribed to cfcdev. To unsubscribe, send an email to cfcdev@cfczone.org with the words 'unsubscribe cfcdev' as the subject of the email. CFCDev is run by CFCZone (www.cfczone.org) and supported by CFXHosting (www.cfxhosting.com). CFCDev is supported by New Atlanta, makers of BlueDragon http://www.newatlanta.com/products/bluedragon/index.cfm An archive of the CFCDev list is available at www.mail-archive.com/cfcdev@cfczone.org ---------------------------------------------------------- You are subscribed to cfcdev. To unsubscribe, send an email to cfcdev@cfczone.org with the words 'unsubscribe cfcdev' as the subject of the email. CFCDev is run by CFCZone (www.cfczone.org) and supported by CFXHosting (www.cfxhosting.com). CFCDev is supported by New Atlanta, makers of BlueDragon http://www.newatlanta.com/products/bluedragon/index.cfm An archive of the CFCDev list is available at www.mail-archive.com/cfcdev@cfczone.org