Laurie Harper wrote the following on 8/4/2005 12:58 PM:
Looking up lists of things is sort of a meta-concern; you're right, putting that on the Employee object would clutter things up, especially when you start needing more complex queries -- e.g. getEmployeesEligibleForPerformanceBonus() etc. Since these kinds of operations are a higher level concern (i.e. they aren't operations on employees but on the entire data class) they should typically live in a higher layer. That's often represented as a 'service' or 'manager' API, which also turns out to be a good place to put business-transaction type operations which also tend to cross-cut across multiple domain objects.
This is EXACTLY what I currently do and even use the term "Service" since it makes sense to me. (I also use regular DTOs in the standard way.. simply a POJO). I guess my question is more to those (Rod?) that say DTOs are a bad idea since I think it makes sense to have them. For example, as your description above you might have a method in a service class that is: getEmployeesEligibleForPerformanceBonus() To me, it also then makes sense to encapsulate other Employee related operations there also including standard CRUD stuff. I find an application to become confusing when operations start being handled in different layers (ie some done from Service/Delegate classes, some called from the ValueObject itself).
OO generally talks about grouping behaviour and data together, so factoring out the properties into a separate object would be less OO than factoring out a sub-set of the behaviour (the CRUD actions).
True, my initial statement was poorly worded, what I meant, though, was in regard to the DTO debate, once you do factor of the CRUD stuff you are left with just your standard DTO, but the distinction you make is noteworthy.
In particular, CRUD actions are not behaviour of the business object ('save employee object to the database' is not an operation that makes sense in the context of the business domain, it's an implementation artifact [speaking broadly]). That's partly what makes them a good candidate for encapsulating separately.
I totally agree, yet this topic seems to come up a lot - where you'll see people state it's 'better design' and 'adheres more to standard OO' to do just the opposite (that is add these kind of CRUD methods to the object in question). I tend to agree that CRUD actions are NOT behaviors of business objects. For example, if working with "Dog" objects a "save" is much different than say "performBark()." Barking, moving, eating owner's shoes, are behavior of a Dog - I don't see CRUD in the same light.
-- Rick --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
