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]