Title: Message
I'm going round in circles on this.
 
One the one hand it seems attractive to put transformation, validation and calculation code into beans. Now they are (at least somewhat) smart.
- MyUser.setPhoneNumber() can now regex to remove non-integers and can return whether the phone number was valid or not (or that could be broken out).
- MyUser.getAge() can calculate the age based on VARIABLES.DateofBirth.
 
But then I ask, what happens when I want to display a list of records on the page and I want to include perhaps a users age that is calculated from UserDateofBirth? Well, unless I want to duplicate my calculation code, I'll have to create a collection of objects (or loop through a recordset loading into and saving out from an object which may be more performant but would be a bit bug eyed and weird) just to display my 100 records on the page. Similarly, if I want to import 100 records, to transform successfully I'd have to either create 100 objects or load and unload an object 100 times.
 
Firstly, is anyone out there using a load/unload single object kind of pattern to make these kinds of systems more performant (as opposed to a less radical example of object pooling such as some of what Sean did in Reactor)?
 
Secondly, what not just go back to a service object (e.g. UserService) operating on recordsets, using DAO and Gateway to abstract database access and if necessary an abstract factory for calling them if you want to support n-data sources. How does putting validation, transformation and/or calculation code in a bean (one object) as opposed to its service (another object) better in terms of maintainability? I'm sure there is a good answer to this, but I can't quite grasp it . . . !
 
Best Wishes,
Peter
 
 
 
----------------------------------------------------------
You are subscribed to cfcdev. To unsubscribe, send an email to cfcdev@cfczone.org 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).

An archive of the CFCDev list is available at www.mail-archive.com/cfcdev@cfczone.org

Reply via email to