A previous
discussion pointed out a great series of posts relating do anemic domain
models:
as well as Martin
Fowlers original anti pattern:
The problem I'm
still trying to grapple with is what heuristics drive what behavior goes in the
bean and what goes into the Service layer?
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?
If you want to
design a system that is capable of handling CRUD (with supporting business
rules) of single objects and lists of n-objects, what kind of domain logic can
you afford to put in the bean given that your solution must be capable of
creating, reading, updating and deleting n-records (where n can be large enough
to make iterating through smart beans a perfomance issue - say 100 or
even 1,000 or 10,000 in the case of imports)?
Does anyone have an
example of any intelligence that you can truly afford to put within the
bean?
Bear in mind I'm
still digging out of the whole procedural mindset, so I'm sure I am missing
something obvious. Just not sure what :-<
Best Wishes,
Peter
----------------------------------------------------------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
