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? ---------------------------------------------------------- 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]
