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]
