First off... a hearty chuckle. I just finished writing this but stopped to read Pete's answer before I sent it. It's entirely different than mine in some respects, so you'll have to read them both and hopefully we're keeping you as confused as we are. Sean Corfield's posted some recently to CFCDev about the difference between beans and TOs... and his posts were mentioned in a blog post or two... so you might find some success with searching either the archives or MXNA. I'll try my best to summarize here as well.
Martin Fowler says that a Value Object is similar to a primitive datatype in a language like CF, a Transfer Object is a collection of data from multiple sources to reduce calls to foreign systems, and never mentions a bean (not surprising, really). What's interesting to note is the vocabular disparity between the OO pros out there (even mentioned in Fowler's entry on TOs at http://martinfowler.com/eaaCatalog/). So I'll give you my first impressions of these terms... how I think of them as I'm working. I think, despite the implementation specifics, you'll find a great deal of similarity in the basic conceptual motivations behinds the use of these terms. At least, I hope you do. :)
Generally I see the term "bean" (and a VO, actually) as referring to an object that has discrete get and set methods for each field in it's instance data. Because of this, it validates everything it consumes and is intended to be a primary data container within an application. Some get methods may return more than a simple reference to a single field... like getAge() calculating the difference between now() and getDOB() and returning an integer. I tend to think of a bean as the basic concept behind almost any CFC I write, and are differentiated from business objects generally by the scope of their behavior.
The term "transfer object" I use in reference to a category of objects used to transfer data between the layers of an application. Where beans feature more granular control over which fields may be get/set by whom via the use of the cffunction's access attribute, a TO might have a generic public get method (i.e. getValue("valueName")) and a private set method (i.e. setInstance(struct)). It may also have a method for getting the whole instance collection (i.e. getInstance()) and possible methods like getValueNamesArray() that returns an array containing the names of the TO's instance fields. I generally use a "memento" style data collection in a TO where all the data in the TO is stored at variables.instance["foo"] because this enables a nice clean way to pull the object's entire state out for a DAO or other handler. [NOTE: I just looked up the term "memento" at the Portland Pattern Repository (the link is on the MachII dev guide in the livedocs thanks to Sean) and it comes from the use of a pattern to allow an objects entire state to be saved for later and easily restored if need be (often for undo/redo operations). In this case, it's a nice way to keep our methods (which are UDFs in a struct key for all intents and purposes) separate from instance data...]
An LTO, as Peter uses the term here, is really a struct-on-steroids implementation that may make minimal use of methods but generally carries all its instance data in it's "this" scope. Unsafe at any speed... but a LOT of fun in the snow. ;) But really, since it's simply meant for the narrow purpose of passing data from your business layer to your DAO it's probably not an issue of large concern. I just like my TOs because they still keep data in the private scope and do encapsulate the data. Once the instance data has been written by whatever has access to the setter (which may be injected via Behavior Inejection and actually removed before passing the TO along), it abides by the TO concept of cutting off (conceptually, anyway) write/edit operations before handing the populated TO along to something else. An LTO isn't really encapsulated at all because the data is carried in its this scope... so it's effectively a CFC-based struct.
In terms of usage, you might have a business object create a bean out of data from a form post... hence the data is validated as the BO feeds the bean (granted, further validation is often necessary, but that's the gist). The business object may then pass that bean to a separate persistence CFC that will convert the bean's data into a TO which it passes to the create() method of a DAO. The DAO may then call getValueNamesArray() or even getInstance() and loop over those names/values to create the data for the query it then issues to the database. Essentially they're all meant to carry data around, but they have different purposes and different ways of doing similar tasks.
Again, it's my take... and it's probably got some inaccuracies -- although it seems that no matter what language you look at some variations always apply... even extreme ones in some cases like the one Fowler mentions in regards to VOs. But, generally, the concepts behind the terms will follow each other fairly closely.
I hope that helps...
Laterz,
J
On 5/8/05, Cliff Meyers <[EMAIL PROTECTED]> wrote:
> Plans for Version 2.0:
> - CFForm (mx7) version as well and the current html/_javascript_
> - Enhanced error handling CFC examples for validation() method
> - Tradition TOs as well as the current LTOs
> - Anything else...?
Just curious here... I thought a bean was a kind of transfer object.
Could you explain the difference between the "traditional" Mach-II
bean and the LTOs?
-Cliff
--
---------------
-------------------------------------
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]
