On 8/4/05, Leon Rosenberg <[EMAIL PROTECTED]> wrote: > Each software system (which is large enough...) has more then one layer. > Different layers usually handles same data. Each of the layers has ist own > view on the data. The business layer, which has to calculate the salary of > an employee is not interested in employee's persistence capabilities. It's > not interested in internal object id (like the one generated by hibernate). > The presentation layer is not interested in employee's identity card > attribute, but solely in presentation issues, like name or similar. > According to the principles of data hiding, a layer should only be able to > access data, which it really needs. Therefore, there is no need that the > employee object which is used by the presentation layer is the same, which > is used by the business layer, and the same which knows everything about > underlying persistence capabilities, like oodb, rdb or file system.
The employee object is employee object, it is the representation of a real-life object. The view of employee object can be different. That is what DTO is, it is a view. > Therefore the DTO object is the protocol, the language spoken between the > layers, and if you want to achieve a layer separation, you need to separate > the view from the data. (Olympic ring metaphor by Ted Husted). You mean, separate view from the business object, not from the data? ;-) Anyway, I am not sure that this separation is needed, unless view layer is developed by an evil third party contractor. > You may say that the DTO's are not OO, because they only contain state and > no behaviour. That's right, but com'on, we are talking about java here, and > java isn't a simple OO language, but a component-oriented language, and DTOs > are part of the component definition. > > As for Rod Johnson, he said that DTOs are evil if you don't want to > distribute the application (arguable point btw, because i believe we should > provide clean application design in any case), but as I said before, we are > talking about _LARGE_SYSTEMS and they are 99% distributed. Rod (or what is Craig or David? I think it was Rod) said that by his assessment, only about 15% of EJB apps are distributed. All other guys simply spent hundreds of man-hours to make app distributable, for no reason. I do not think that this percentage is higher for non-EJB apps. What is really needed for distributed apps is Serializable objects. > For a HelloWorld applet, or a small address management programm, I probably > don't need DTOs. As soon, as I have more then one component - I do. > > > Regards > Leon > > P.S. By the way, Rod Johnson also said persistent objects that contain only > getters and setters are evil too (same page as dto, 27). In my understanding > it means hibernate and ibatis which use such objects are at least as evil? > How are you supposed to represent data anyway then? If getters and setters do nothing more than simply read field or set field, then they are evil, you do not need Rod Johnson to tell you that ;) Problem with Java that it got a lot of new stuff in 1.5, but it still does not have normal properties like Delphi has or at least like C# has. If a class member could have different access modifiers for read and write, then getters and setters would not be needed in most of cases. Delphi properties rule, Java getters/setters suck, this is for sure. Michael. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
