Rick Reumann on 04/08/05 19:12, wrote:
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.
If a dog must save itself when it changes but cannot have the action as
a behaviour, you immediately accept the necessity of a persistence
layer. Hence Hibernate, EJB CMP, etc and the DAO pattern.
So where does that leave the DTO? By my way of thinking (a dangerous
area indeed most likely) it is still very OO to have a class with
business methods, but where the data is encapsulated within the DTO,
which itself as a whole is a property or an item in a collection, rather
than a whole series of getters, setters and private properties.
But it's getting late so I'm willing to be proved wrong.
Adam
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
