Re: [OT] DTOs are evil
On 8/5/05, Leon Rosenberg <[EMAIL PROTECTED]> wrote: > On Fri, 2005-08-05 at 08:13 -0600, Larry Meadors wrote: > > > > > Who cares? is opacity not the point of Object Oriented-ness? > > > > maybe. But code readability is the more important feature :-) > > leon Agreed, and IMO, the C# version is more readable, too. ;-) Larry - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [OT] DTOs are evil
On 8/5/05, Leon Rosenberg <[EMAIL PROTECTED]> wrote: > On Fri, 2005-08-05 at 08:13 -0600, Larry Meadors wrote: > > > > > Who cares? is opacity not the point of Object Oriented-ness? > > > > maybe. But code readability is the more important feature :-) > > leon Agreed, and IMO, the C# version is more readable, too. ;-) Larry - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [OT] DTOs are evil
Agreed. /me shudders... Larry On 8/5/05, Dave Newton <[EMAIL PROTECTED]> wrote: > Daniel Perry wrote: > > >you can do that without the getter/setter in java as MyProperty is public. > > > > > Public properties--now _that_ is evil! > > Dave > > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [OT] DTOs are evil
On 8/5/05, Leon Rosenberg <[EMAIL PROTECTED]> wrote: > On Thu, 2005-08-04 at 17:05 -0700, Michael Jouravlev wrote: > > 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. > > I give you a RL example. We have a relative large portal here, with some > 10.000 classes and thousands of requests pro second, with large > databases in the back etc. > Our development environment contains at least 3 server for each test > cycle (unstable, stable-develop, integration, test). So it's about 12 > machines you need as developer. Still I like to work at home from time > to time. I can't afford having 12 high-end machines at home. Instead we > have alternative implementations for all persistence layers, which go to > inmemory dbs or filesystems instead of real dbs. The business layer is > the same. We only switch the persistence layer and as by magic, it all > runs on my notebook. If my business object would encapsulate this > knowledge, i wouldn't be able to do this. But as we are > component-oriented we switch complete components. I did not argue with above... > It wouldn't be possible without DTOs. ...but this is I am not sure about. You explained DAO, not DTO. > As for the Serializable -> you know something slower then that? I don't. > If you are playing around, you can distribute with serializable and RMI, > sure thing. If you need performance - forget it. I will not argue with that, frankly I did not do tests myself. > Example: > private String mail; > public String getMail(){ > return mail; > } > > public void setMail(String aMail){ > mail = aMail; > } > > why is that uglier then direct property access? The above syntax already pretty ugly, but do not forget the comments for the field, for getter and for setter. Of course you can write: private String mail; public String getMail() {return mail;} public void setMail(String aMail) {mail = aMail;} which still does not look beautiful, but at least relatively compact. If I could write one comment above this group, like "this is mail property, use legitimate [EMAIL PROTECTED] syntax" and it would apply to this group like to a property, that would be ok. But javadoc does not know properties, it lists methods and fields, which is too much for simple cases like this. On 8/5/05, Larry Meadors <[EMAIL PROTECTED]> wrote: > Now, instead of: > > someValue = foo.getMyProperty(); > foo.setMyProperty(someValue); > > ...I can do this instead: > > someValue = foo.MyProperty; > foo.MyProperty = someValue; Exactly. Do not forget, that C# was created by the guy who created Delphi ;) On 8/5/05, Frank W. Zammetti <[EMAIL PROTECTED]> wrote: > I would personally tend to agree the C# syntax is cleaner... but I don't > think the difference is all that big frankly and it probably comes down to > a matter of developer proference rather than what's actually "better" in > some way. You can use Object Pascal / C# property as rvalue or lvalue. You can define property to point to actual private field directly, and then refactor it, using methods. Notice that client would not know about it! In Java you have to use either getter or setter, and refactoring from using field directly to using getters is a pain since it affects clients of your object. Java properties suck. I don't even mention that there is no *simple* way to create Java property accessible from IDE. Michael. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [OT] DTOs are evil
Daniel Perry wrote: you can do that without the getter/setter in java as MyProperty is public. Public properties--now _that_ is evil! Dave - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [OT] DTOs are evil
Leon Rosenberg wrote: On Fri, 2005-08-05 at 08:13 -0600, Larry Meadors wrote: Who cares? is opacity not the point of Object Oriented-ness? maybe. But code readability is the more important feature :-) If I'm reading the code and see a property access all I need to know is that I'm accessing a property. I'd argue that at that level of code inspection I _shouldn't_ know if it's going through a method or not. If I implemented the property accessor then it's trivial to jump to the accessor definition via IDE/whatever, if it's a black-box class then I'll never know anyway. There's no appreciable difference in functionality, but I think the C# implemetnation is marginally cleaner because: (a) No annoying get/setXXX() (minor, and essentially irrelevent-with clever IDE/editor usage I never have to type it anyway) (b) Properties are defined in their own block--nice in folding editors and visually obvious. Dave - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [OT] DTOs are evil
I would personally tend to agree the C# syntax is cleaner... but I don't think the difference is all that big frankly and it probably comes down to a matter of developer proference rather than what's actually "better" in some way. They both functionally *DO* the same thing though... your executing code to set and get private properties of an object. The original topic here is "DTOs are evil", and it seems to me that the syntax of C# wouldn't change a persons' opinion on that question, right? I mean, if DTOs are evil in your mind, they aren't suddenly *NOT* evil simply because C# might offer a syntax you like more, does it? :) The example you gave in C# is functionally equivalent to the Java version, so if the basic premise is dealing with what should actually happen in the getters and setters, C# doesn't make the situation better in that regard. -- Frank W. Zammetti Founder and Chief Software Architect Omnytex Technologies http://www.omnytex.com On Fri, August 5, 2005 9:18 am, Larry Meadors said: > You don't see it?!? Have you looked? > > As a self-professed Java bigot, I will readily admit that C# has a > *way* better sytax for defining and using properties that I wish Java > would implement (or even better - improve upon). > > public string MyProperty { > get { return myProperty; } > set { myProperty = value; } > } > > Now, instead of: > > someValue = foo.getMyProperty(); > foo.setMyProperty(someValue); > > ...I can do this instead: > > someValue = foo.MyProperty; > foo.MyProperty = someValue; > > IMO, the second form is MUCH clearer, and provides all of the benefits > of a get/set pair. > > Larry > > > On 8/5/05, Leon Rosenberg <[EMAIL PROTECTED]> wrote: >> >> Sorry, I don't see it. >> >> Example: >> private String mail; >> public String getMail(){ >> return mail; >> } >> >> public void setMail(String aMail){ >> mail = aMail; >> } >> > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [OT] DTOs are evil
On Fri, 2005-08-05 at 08:13 -0600, Larry Meadors wrote: > > Who cares? is opacity not the point of Object Oriented-ness? > maybe. But code readability is the more important feature :-) leon - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [OT] DTOs are evil
On 8/5/05, Leon Rosenberg <[EMAIL PROTECTED]> wrote: > On Fri, 2005-08-05 at 07:18 -0600, Larry Meadors wrote: > > You don't see it?!? Have you looked? > > > > As a self-professed Java bigot, I will readily admit that C# has a > > *way* better sytax for defining and using properties that I wish Java > > would implement (or even better - improve upon). > > > > public string MyProperty { > > get { return myProperty; } > > set { myProperty = value; } > > } > > > > Now, instead of: > > > > someValue = foo.getMyProperty(); > > foo.setMyProperty(someValue); > > > > ...I can do this instead: > > > > someValue = foo.MyProperty; > > foo.MyProperty = someValue; > > > It looks better ... on the first glance. > How do I distinguish if > foo.MyProperty = someValue; > is going through a setter or not (without looking into the code)? > Who cares? is opacity not the point of Object Oriented-ness? My argument is just the opposite: With C#, I can add a field, and encapsulate it later with this syntax, can you do the same with getProp/setProp pairs? No. Score one more for the C# kids. In this realm, C# is clearly superior. Larry - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [OT] DTOs are evil
eh? you can do that without the getter/setter in java as MyProperty is public. Daniel. > -Original Message- > From: Larry Meadors [mailto:[EMAIL PROTECTED] > Sent: 05 August 2005 14:18 > To: Struts Users Mailing List > Subject: Re: [OT] DTOs are evil > > > You don't see it?!? Have you looked? > > As a self-professed Java bigot, I will readily admit that C# has a > *way* better sytax for defining and using properties that I wish Java > would implement (or even better - improve upon). > > public string MyProperty { > get { return myProperty; } > set { myProperty = value; } > } > > Now, instead of: > > someValue = foo.getMyProperty(); > foo.setMyProperty(someValue); > > ...I can do this instead: > > someValue = foo.MyProperty; > foo.MyProperty = someValue; > > IMO, the second form is MUCH clearer, and provides all of the benefits > of a get/set pair. > > Larry > > > On 8/5/05, Leon Rosenberg <[EMAIL PROTECTED]> wrote: > > > > Sorry, I don't see it. > > > > Example: > > private String mail; > > public String getMail(){ > > return mail; > > } > > > > public void setMail(String aMail){ > > mail = aMail; > > } > > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [OT] DTOs are evil
On Fri, 2005-08-05 at 07:18 -0600, Larry Meadors wrote: > You don't see it?!? Have you looked? > > As a self-professed Java bigot, I will readily admit that C# has a > *way* better sytax for defining and using properties that I wish Java > would implement (or even better - improve upon). > > public string MyProperty { > get { return myProperty; } > set { myProperty = value; } > } > > Now, instead of: > > someValue = foo.getMyProperty(); > foo.setMyProperty(someValue); > > ...I can do this instead: > > someValue = foo.MyProperty; > foo.MyProperty = someValue; It looks better ... on the first glance. How do I distinguish if foo.MyProperty = someValue; is going through a setter or not (without looking into the code)? Leon - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [OT] DTOs are evil
You don't see it?!? Have you looked? As a self-professed Java bigot, I will readily admit that C# has a *way* better sytax for defining and using properties that I wish Java would implement (or even better - improve upon). public string MyProperty { get { return myProperty; } set { myProperty = value; } } Now, instead of: someValue = foo.getMyProperty(); foo.setMyProperty(someValue); ...I can do this instead: someValue = foo.MyProperty; foo.MyProperty = someValue; IMO, the second form is MUCH clearer, and provides all of the benefits of a get/set pair. Larry On 8/5/05, Leon Rosenberg <[EMAIL PROTECTED]> wrote: > > Sorry, I don't see it. > > Example: > private String mail; > public String getMail(){ > return mail; > } > > public void setMail(String aMail){ > mail = aMail; > } > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [OT] DTOs are evil
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? the issue is not the getters and setters per se. it's the "anemic domain model" antipattern where domain logic that *should* have gone in persistent domain objects is written procedurally, not fully leveraging the OOP facilities to uphold the DRY principle. The tangible symptom is copy-pasted logic, or frequent calls to a static helper method that takes a domain object as a parameter. EJB entity beans forces you into the anemic domain antipattern because all your getters/setters have to be public, preventing you from enforcing invariants on the bean itself. Hibernate gives you more flexibility by allowing private getters/setters, so you can enforce some business logic in the domain object itself. [1] http://www.theserverside.com/news/thread.tss?thread_id=31010 -- Bill - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [OT] DTOs are evil
On Thu, 2005-08-04 at 17:05 -0700, Michael Jouravlev wrote: > 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. I give you a RL example. We have a relative large portal here, with some 10.000 classes and thousands of requests pro second, with large databases in the back etc. Our development environment contains at least 3 server for each test cycle (unstable, stable-develop, integration, test). So it's about 12 machines you need as developer. Still I like to work at home from time to time. I can't afford having 12 high-end machines at home. Instead we have alternative implementations for all persistence layers, which go to inmemory dbs or filesystems instead of real dbs. The business layer is the same. We only switch the persistence layer and as by magic, it all runs on my notebook. If my business object would encapsulate this knowledge, i wouldn't be able to do this. But as we are component-oriented we switch complete components. It wouldn't be possible without DTOs. > > > 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. Yes Rod said only 15% of EJB apps are distributed. But this was a critic on EJB, since in EJB you have to decide early, if you distribute or not. If you have a transparent middleware layer, which allows you to develop monolithic and run distributed you don't care about it. We have such a middleware, CORBA is such a middleware and Spring offers similar mechanism too. You have to care about good coding style, like submitting return values in hashmaps given as in-parameters will not work distributed, but you wouldn't do it either way, right? As for the Serializable -> you know something slower then that? I don't. If you are playing around, you can distribute with serializable and RMI, sure thing. If you need performance - forget it. > > > > 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/sette
Re: [OT] DTOs are evil
Michael Jouravlev wrote: Yes, this is exactly what I mean. This is evil. I take that you have not used Object Pascal? I've actually seen it, although I can't say I've personally used it. property MaxLength: Integer read FMaxLength write SetMaxLength default 0; There's nothing to stop you from doing: private Integer MaxLength; public void setMaxLength(Integer MaxLength) { this.Maxlength = MaxLength; } public Integer getMaxLength() { return this.MaxLength(); } Well, nothing except knowing it's a bad style :) And no, I'm not trying to compare that single OPascal line and this, clearly the Pascal line is cleaner. Is this so hard to implement in the compiler? I certainly wouldn't think so. I'd be willing to bet there is a reason it hasn't been done before though because I agree it would make a lot of sense. Why anyone would call that evil I don't understand. Care to convince me it is? :) See above ;-) I guess I took the word "evil" quite literally :) I agree what Java offers in this regard is probably sub-par, but I still think there is enough value in a class that does the bare minimum, just in terms of organization, to not want to attach the word "evil" to it... if you said "non-optimal", I would agree :) Michael. Frank - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [OT] DTOs are evil
On 8/4/05, Frank W. Zammetti <[EMAIL PROTECTED]> wrote: > Michael Jouravlev wrote: > > 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 ;) > > I think I may... why exactly is this evil? > > We're talking, at the most basic level, about a construct that > encapsulates properties of a modeled object behind a (theoretically) > well-defined interface. If you do it right you can change details of > the implementation without altering client classes. > > This is all nothing anyone reading this doesn't know of course :) > > If you mean a class who's accessors and mutators simply do: > > return this.field; > > and > > this.field = field; > > ...then, while I'm not sure I would call it "evil", certainly that isn't > using the concept to its full potential. Yes, this is exactly what I mean. This is evil. I take that you have not used Object Pascal? It is not just for kiddies. Check this article, for example: http://www.informit.com/articles/printerfriendly.asp?p=26862 === cut here === TCustomEdit = class(TWinControl) private FMaxLength: Integer; protected procedure SetMaxLength(Value: Integer); ... published property MaxLength: Integer read FMaxLength write SetMaxLength default 0; ... end; === cut here === Here TCustomEdit is a component, and MaxLength is a property (it does not have to be published, but if it is, then it automatically shows in IDE property editor). You can define either only getter, or only setter or both. You can map private field directly or use method. You can set default value as well. Indexed properties are supported too. Java 5 got annotations and generics, but still does not have properties, that are easy to use, and could be set from IDE. Oh, right, original Javabean specification has something about that, but getters and setters is all that really left from the spec. Probably because it was not simple enough. Considering the commenting style and how javadoc assign comments to methods and groups them in the help file, one simple Java property is at least half a screen of garbage. Instead I would prefer to have: property MaxLength: Integer read FMaxLength write SetMaxLength default 0; Is this so hard to implement in the compiler? > Why anyone would call that evil I don't understand. Care to convince me > it is? :) See above ;-) Michael. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [OT] DTOs are evil
Michael Jouravlev wrote: 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 ;) I think I may... why exactly is this evil? We're talking, at the most basic level, about a construct that encapsulates properties of a modeled object behind a (theoretically) well-defined interface. If you do it right you can change details of the implementation without altering client classes. This is all nothing anyone reading this doesn't know of course :) If you mean a class who's accessors and mutators simply do: return this.field; and this.field = field; ...then, while I'm not sure I would call it "evil", certainly that isn't using the concept to its full potential. The public interface should also be "well-behaved", i.e., should handle incorrect data types and nulls and things like that gracefully. But even that argument seems to me less important than the basic concept of a well-organized data structure to describe some modeled object, and that's what you have even if the methods are doing nothing but like the above. Why anyone would call that evil I don't understand. Care to convince me it is? :) -- Frank W. Zammetti Founder and Chief Software Architect Omnytex Technologies http://www.omnytex.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [OT] DTOs are evil
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]
Re: [OT] DTOs are evil
> -Ursprüngliche Nachricht- > Von: Michael Jouravlev [mailto:[EMAIL PROTECTED] > Gesendet: Donnerstag, 4. August 2005 23:27 > An: Struts Users Mailing List > Betreff: Re: DTOs are evil > So, DTOs are useful where: > * model was done incorrectly > * in cases of really severe bandwidth contstraints > * for sets (lists) of objects > Sorry, but i can't resist replying. In opposite to the above said, i'd postulate that each software system, which is large enough to be of interest (like in Goedels theorem :-)) , must have DTOs (or ValueObjects) or it was incorrectly modeled. 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. 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 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. 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? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]