You may well be right Barney. It is fully possible that my labels and/or concepts are out of whack. I'll take a crack at it:
To me a TO is basically a simple struct, but possibly wrapped up as a CFC with public instance data. This would be just for moving data around with no other functionality. A Business Object represents a real-world entity in the model. This is where the real business logic happens, and may involve composition of other objects (maybe many), lots of "coding by intention" (meaning "sergeant" and "private" methods), and in general doing the work of the model. A Bean, as I see it, is a sort of intermediary. It is like a TO except that it has getters and setters, and very likely (but not always) the setters are private so the data can't be changed once the Bean is created. It keeps instance data, and it also validates itself (with potentially complex validation). But that is all. Any real business logic would be performed by a BO, and a Bean would be passed into the BO (or the DAO for example) to move the data around. So, assuming that made any sense, what do you think? And am I way off in my impression of what each of these are? Thanks for your time as always. Brian On 8/26/05, Barney Boisvert <[EMAIL PROTECTED]> wrote: > It depends. (duck and cover ;) > > I almost never use TOs, prefering simple structs. You don't get the > immutability of a TO with a struct, but since the data is a copy of > the "real" data, anything that changes the data is only going to screw > itself up. It's a lot easier (and somewhat more performant) than > using a full-on object, and I've never run into a problem with it. > > Bean/BO is little less clear. I don't make a distinction. Some of my > BOs are nothing more than get/set/validate (where the validation is > generated based on the DB schema), and some are masses of composition > and business logic methods, including custom validation. But the rest > of the system doesn't care, a BO is a BO, and it has zero or more > business methods. > > Having said that, I think your definition of "Bean" (at least from > your email) is a little unclear. What do you use a bean for that you > wouldn't use a TO or a BO for (assuming a given entity had all three). > > cheers, > barneyb > > On 8/26/05, Brian Kotek <[EMAIL PROTECTED]> wrote: > > A question here for the list. I'd like to know at what points you > > decide to create a full business object vs. creating a Bean vs. > > creating a transfer object. And don't just say "it depends"! Just > > kidding...say it depends but try to explain what you think it depends > > on. > > > > For example, if an entity isn't that complex, I've found that what I > > call a Bean can handle all three chores. On one hand creating a TO for > > a fairly simple Bean seems like overkill, and creating a full business > > object behind a Bean can also seem like overkill if the BO isn't doing > > much that the Bean is already doing, such as validating itself and > > holding instance data. > > > > In fact, in most cases, unless the bean is really heavy (maybe > > compositing a complex Validation object within itself) I have little > > use for transfer objects. > > > > Of course if the entity requires complex business logic then a > > full-fledged business object is in order, there is no place for that > > kind of logic in a Bean. > > > > I suppose the real point is that a good manager or service object is > > necessary to hide these variations. As long as the UI is going through > > a manager, you can change how the underlying model is doing things > > fairly easily. What does everyone else think? > > > > > > > -- > Barney Boisvert > [EMAIL PROTECTED] > 360.319.6145 > http://www.barneyb.com/ > > Got Gmail? I have 50 invites. > > > ---------------------------------------------------------- > 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] > > > ---------------------------------------------------------- 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]
