Rick Reumann wrote:
I do agree, though, with what others have said that DTOs/ValueObjects
aren't really that OO. It's funny that the subject comes up because I
was a late bloomer to the programming world (started about 6 years and
was a waiter and science teacher before that:), and when I first started
reading the Java books and then applying that to what I was
reading/seeing in JSP projects I was on, the concepts did seem to conflict.
What I mean is take the concept of an "Employee." In almost all web
applications you see the EmployeeDTO being passed to the DAO...
employeeDAO.updateEmployee( employee );
From what I recall the real OO way would be...
employee.update();
and employee takes care of updating itself.
The idea of a DTO is to encapsulate the persistence logic so that it can be
independent of the model representation and business logic, and easily
replaceable. There's nothing saying you can't put an update() method on
your business objects and have it delegate to a DTO but you risk having an
explosion of data access methods on your business objects that way. Since
persistence is typically a quite separate concern from other domain logic,
it makes sense to separate it out.
From an OO perspective I don't see a problem having an Employee object
that has a DAO inside that takes care of persistence. I do have a couple
questions though about OO design if this approach is used...
1) Where do you encapsulate getting Collections back of your objects?
For example an Employee object has CRUD methods, but what about you when
you need a List of Employees? Do you make an EmployeeList object that
has methods getEmployees? Do you maybe just 'cheat' and add a getList or
getEmployees method directly to the Employee object?
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.
2) It also seems a bit heavy to return Collections of pretty heavy
objects. (Each Employee since it's not a simple VO could be a large
object - although by large I just mean having a bunch of methods in it
etc - I'm not so sure it would be large footprint-wise if just the
properties were being filled in the case of a list - so bottom line is
maybe the extra stuff in the object doesn't matter much?
It depends on how 'connected' your domain objects are. If an employee
references a manager and a manager contains a collection of reports and ...
then you need to care about how much of the object graph you load when you
load each employee. different persistence frameworks and ORM tools have
different ways of managing this. If you need most of the data stored on an
employee from the list, returning a list of employees makes sense. If you
only need a sub-set of the properties on each employee, returning an
intermediate representation of the specific data query will make more sense.
Side note...
3) Even from an OO perspective, you always hear about encapsulating
unique behaviors to make things reusable, so in a sense couldn't you
consider the 'properties' of an Employee 'unique' or, if not the
properties, the CRUD stuff is 'sort of' unique? If this is the case, you
could make an argument for separating out the properties into another
object (DTO/VO) separate?
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). 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.
L.
--
Laurie, Open Source advocate, Java geek and novice blogger:
http://www.holoweb.net/laurie
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
