Michael Jouravlev wrote the following on 8/3/2005 9:07 PM:
http://www.theserverside.com/news/thread.tss?thread_id=35233
Just curious what are Rod's exact views on the DTO? I searched for DTOs
on that link you posted but only saw posts by other people.
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.
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?
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?
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?
--
Rick
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
