You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@struts.apache.org by Michael Jouravlev <jm...@gmail.com> on 2005/08/05 02:05:46 UTC
Re: [OT] DTOs are evil
On 8/4/05, Leon Rosenberg <st...@anotheria.net> 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: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: [OT] DTOs are evil
Posted by "Frank W. Zammetti" <fz...@omnytex.com>.
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: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: [OT] DTOs are evil
Posted by Michael Jouravlev <jm...@gmail.com>.
On 8/4/05, Frank W. Zammetti <fz...@omnytex.com> 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: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: [OT] DTOs are evil
Posted by "Frank W. Zammetti" <fz...@omnytex.com>.
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: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: [OT] DTOs are evil
Posted by Larry Meadors <la...@gmail.com>.
Agreed.
/me shudders...
Larry
On 8/5/05, Dave Newton <ne...@pingsite.com> 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: user-unsubscribe@struts.apache.org
> For additional commands, e-mail: user-help@struts.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: [OT] DTOs are evil
Posted by Dave Newton <ne...@pingsite.com>.
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: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
RE: [OT] DTOs are evil
Posted by Daniel Perry <d....@netcase.co.uk>.
eh? you can do that without the getter/setter in java as MyProperty is
public.
Daniel.
> -----Original Message-----
> From: Larry Meadors [mailto:larry.meadors@gmail.com]
> 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 <st...@anotheria.net> 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: user-unsubscribe@struts.apache.org
> For additional commands, e-mail: user-help@struts.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: [OT] DTOs are evil
Posted by Larry Meadors <la...@gmail.com>.
On 8/5/05, Leon Rosenberg <st...@anotheria.net> 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: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: [OT] DTOs are evil
Posted by Larry Meadors <la...@gmail.com>.
On 8/5/05, Leon Rosenberg <st...@anotheria.net> 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: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: [OT] DTOs are evil
Posted by Dave Newton <ne...@pingsite.com>.
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: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: [OT] DTOs are evil
Posted by Leon Rosenberg <st...@anotheria.net>.
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: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: [OT] DTOs are evil
Posted by Larry Meadors <la...@gmail.com>.
On 8/5/05, Leon Rosenberg <st...@anotheria.net> 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: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: [OT] DTOs are evil
Posted by Leon Rosenberg <st...@anotheria.net>.
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: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: [OT] DTOs are evil
Posted by Michael Jouravlev <jm...@gmail.com>.
On 8/5/05, Leon Rosenberg <st...@anotheria.net> 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 a@b.c 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 <la...@gmail.com> 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 <fz...@omnytex.com> 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: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: [OT] DTOs are evil
Posted by "Frank W. Zammetti" <fz...@omnytex.com>.
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 <st...@anotheria.net> 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: user-unsubscribe@struts.apache.org
> For additional commands, e-mail: user-help@struts.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: [OT] DTOs are evil
Posted by Larry Meadors <la...@gmail.com>.
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 <st...@anotheria.net> 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: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: [OT] DTOs are evil
Posted by Leon Rosenberg <st...@anotheria.net>.
On Thu, 2005-08-04 at 17:05 -0700, Michael Jouravlev wrote:
> On 8/4/05, Leon Rosenberg <st...@anotheria.net> 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/setters suck, this is for sure.
>
Sorry, I don't see it.
Example:
private String mail;
public String getMail(){
return mail;
}
public void setMail(String aMail){
mail = aMail;
}
why is that uglier then direct property access?
I have a well-defined interface and full control.
I distribute it, and notice that my app crashes, because my middleware
layer can't handle nulls (as example). I change the implementation of
the method:
public String getMail(){
return mail == null ? "" : mail;
}
This is ABSOLUTELY OO :-)
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org