Cliff, one thing we were stuck on is when bean validation is driven totally off the database, whether it's part of the schema (db field takes 20 chars, not null) or directly off values in another part of the database (if XYZ value is NULL then this value is required)
it's getting the data into the bean to drive these validation rules that had us pondering.... any thoughts? thanx barry.b On 3/7/06, Cliff Meyers <[EMAIL PROTECTED]> wrote: > On 3/5/06, Peter Bell <[EMAIL PROTECTED]> wrote: > > > > Most common example of bean logic is validation (so set#Property# can > > validate the property). I can see how that works great with one object or > > even a handful, but what if you're updating price on 40 records - or > > importing 2,000 from a flat file? If you create a bean for each and use an > > iterator, I'm guessing performance will be an issue. If you use the service > > layer to loop through a dumb dataset then you have to add the validation > > logic to the service layer. If you have the validation logic in the service > > layer, how can you put it into the bean without repeating yourself? > > Fowler's Specification pattern might be one way. It is very commonly > used for validation. That way your service layer and domain entities > could use validation code that exists only in one Class. I would also > Google for his Contextual Validation pattern (it's still in "beta" I > believe). Basically it just states that you should avoid having a > simple "isValid()" method for domain entities and instead anticipate > that different validation rules will apply for different object > states, thus leading to more descriptive, use-case driven methods such > as "isValidForCreation()" or "isValidForShipment()". Coupling that > approach with his Notification pattern allows for a nice way of > grouping multiple validation errors together in a single "message" > object which allows for a very clean way of doing form validation. > > I'm not sure if you need to be too worried about the cost of > instantiating entities and calling validation methods compared to the > cost of writing to the database. It might be a problem, it might not. > But if you're going to call a single UPDATE or INSERT statement for > each loop iteration through your data set I think you'll find that's > where the bottleneck ultimately apoears. The problem of performance > is that simple CRUD DAOs have no notion of batching or "write behind." > Some of the ORM frameworks in the Java world (Hibernate being one) > solve this problem really well, although it usually requires a little > extra configuration to tip the tool off that a big dataset is about to > be processed. > > > HTH, > > Cliff > > > ---------------------------------------------------------- > 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). > > 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). An archive of the CFCDev list is available at www.mail-archive.com/[email protected]
