If in your view you prefer to write syntax such as #myTo.someValue# as opposed to #myBean.getSomeValue()#
Obviously this is kind of trivial. But I think the first one is "cleaner". I use TO's when passing into a view and Beans when passing out of a form.
Typically Only the M and C of my application ever see a bean. The V would only see TOs.
View (Form) -> Controller -> Bean -> Validate() | onFail -> TO -> Controller -> View
View (Form) -> Controller -> Bean -> Validate() | onPass -> Controller -> Model
In the end I think alot of the decision comes down to personal style for most apps. However, If I have disparate systems interacting with mine, when passing data out to them to consume, I think a TO is a much smarter choice. My TO has a MUCH smaller footprint and thus makes for more rapid transfer and, cumulatively, far less bandwidth consumption.
Bill
On 5/9/05, Jared Rypka-Hauer - CMG, LLC <[EMAIL PROTECTED]> wrote:
Pat,
Did you read my post from the Form Validation thread about my view of beans/VOs/TOs? I'm using something akin to your level 2... I outlined it in detail in that thread. If you'd like i can repost it to this thread...
And I generally agree about the transition to level 3... it strikes me as a waste. If you're going to go all-out with discrete get/set methods on your TOs why not just pass the bean... it makes just as much sense.
Laterz,
JOn 5/9/05, Pat Branley < [EMAIL PROTECTED]> wrote: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
--
---------------
-------------------------------------
Buy SQLSurveyor!
http://www.web-relevant.com/sqlsurveyor
Never make your developers open Enterprise Manager again. ----------------------------------------------------------
You are subscribed to cfcdev. To unsubscribe, send an email to [email protected] 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/[email protected]
--
[EMAIL PROTECTED]
http://blog.rawlinson.us
If you want Gmail - just ask. ----------------------------------------------------------
You are subscribed to cfcdev. To unsubscribe, send an email to [email protected] 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/[email protected]
