Nope, sure aren't. Validation is really the fundemental entity-level business operation, in my view. If you are concerned, implementing a pooling mechanism (perhaps where pool management is handled asynchronously via the async event gateway), will alleviate the instantiation problem, because you'll just be pulling an unused instance and populating it.
That'd be the first tact I'd consider if I found instantiation overhead to be a problem, but I haven't gotten to that point yet (I.e. hardware is still cheaper than optimizing). And really, I suspect that "do something" request are almost never the most heavily loaded parts of an application, so this bottleneck won't arise very often. You said "if you want to validate your BO before, say, you send it to a DAO", as if implying that sometimes you don't do that, and therefore potentially allow persistance of invalid entities? My managers (which are also autogenerated) are the only objects that get to talk to the DAOs, and they never do insert or update without a valid BO. I will say that I've broken that rule once, for user accounts that were migrated and the old structure had different requirements than the new, and so it was possible for old accounts to be invalid. We had to deal with that, so I added a flag that allowed persistance of a invalid user object when explicitly requested, because we needed to do some operations that weren't user initiated (like updating expired passwords), and so couldn't force the "user" to fix the invalid info. cheers, barneyb On 9/1/05, Brian Kotek <[EMAIL PROTECTED]> wrote: > Barney, a while back you wrote: > > "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." > > I'm curious, if you want to validate your BO before, say, you send it > to a DAO, are you concerned about instantiating a potentially "heavy" > CFC just to set for valid data? I'm just curious. On advantage I can > see to having a "Bean" that validates itself before you create a BO is > that you avoid unnecessarily creating a complex BO if the data isn't > valid. I know in general we shouldn't design around possible > performance issues but rather actual performance issues, I just > thought I'd get your take. > > Thanks. -- Barney Boisvert [EMAIL PROTECTED] 360.319.6145 http://www.barneyb.com/ Got Gmail? I have 100 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]
