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]
