I wish to tell you a story, to show because I changed my mind about DTOs.
Once upon a time I used to write GUIs (i.e. Swing GUIs). I have to tell
that I used to mix controller code with model. But when I think about that
"era" I noticed that it was pretty easy to write code. Why now is it so
difficult?
The answer is simple: the technology switch changed not only the
purely-technical aspects of programming, but also the way we code. We all
now have the burden of using servlets (directly or indirectly), servlets
mean HTTP requests, sessions, scopes, contexts, things that in GUIs we
never imagined. I think that we once code the OOP way, now we returned to
some sort of procedural programming, i.e. it is like emulating BASIC in
Java :-P
For example, take the Business Delegate pattern (that once I loved a lot
and now this love finished). It is a collection of business methods, not a
real object! Its methods act on different objects, not itself or related
objects! Is it OOP?
About DAOs, they are a way of storing objects, not part of the object
itself. I mean, the DAO calls must be inside the implementation of the
objects, not in their interface!
For example, suppose that you want to connect an object of class B to an
object of class A.

public class A {
  public void addB(B b);
  public List getBs();
}

I think the DAO call must be present in "addB" implementation or you have
to code a sort of "committer" that takes all the requests from domain
objects and then, when a "commit" method is invoked, it commits using
DAOs.
And maybe a very-big object that represents the whole model for the
current "status" (notice that I used "status" and not "user", "session",
etc.) that gives away objects to everyone needs them.
Hello! It is a "document", as in "Document/View" architecture!
You may ask now what's the place for HttpServletRequest and its company. I
think its natural place is inside the document itself, hidden inside its
code, so that the interface is independent from the use of servlet
technology. In fact HttpServletRequest is a relevant part of the status
(current requests, session objects, etc.) but the status must be
"extracted" from the request.
Maybe the MVC pattern should be renamed "DVC" (D obviously stands for
"Document"), so maybe we'll return to real OOP.
Ciao
Antonio Petrelli

P.S.: All the things I told are to be intended as "IMHO". They are neither
patterns nor real code.
P.P.S.: I think DVC is a trademark, so maybe it can't be used :-P

[EMAIL PROTECTED] wrote:

>Hi, Gurus,
>
>Background: I just started a Struts project with Hibernate.  I have
chosen to use the Data Access Object with (Abstract Factory) design
pattern because my client uses Oracle and I use Postgresql database.  I am
working with other teams remotely and they decided to use DTO.
>
>Problem: A few months ago, I recall a message thread on this list with a
subject header of: 'DTOs are evil'.  Since I am new to this, I am having
problems understanding why.  I thought that DTO are for data storage and
data transfer between Business and Value Objects.
>
>Questions: I have the following questions:
>
>1. Why I shouldn't choose it?
>
>2. Should I be using the Apache Commons BeanUtils in my action?  It has a
method like BeanUtils.copyProperties(...).
>
>3. If not BeanUtils, then what do you recommend?
>
>
>Thanks,
>
>Bob
>


---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to