And my
best answer to my own question?
Ask
the question for each piece of behavior: does it relate to object or
entity/class. If it has the possibility of relating to n-objects where n could
be a large number, put the method into some kind of stateless session
bean/service layer. I personally put all CRUD into that category because my apps
have to be capable of adding, editing, viewing and deleting single objects,
lists of selected objects and/or large sets of objects (e.g. import/export
features) so I put those into the service layer which in turn calls the
appropriate DAO for persistence (as a design requirement is the ability to
persist to n-persistence mechanisms).
Examples of object relevant behaviour might be authenticating a
user or calculating the value of a shopping cart as those are operations
that are unlikely to be performed against large collections of the
objects (at least I can't immediately think up a good use case for
"authenticate users where usergroup =x".
Best
Wishes,
Peter
Peter
---------------------------------------------------------------Original Message-----
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Peter Bell
Sent: Sunday, March 05, 2006 3:46 PM
To: [email protected]
Subject: [CFCDev] One more time on anemic domain models . . .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
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]
