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/04 03:07:29 UTC
DTOs are evil
http://www.theserverside.com/news/thread.tss?thread_id=35233
If Rod Johnson have the same position on DTOs as me, should I be twice
confident in my point of view? ;-)
Michael.
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: DTOs are evil
Posted by Dakota Jack <da...@gmail.com>.
The operative word here is "if". An "if-then" statement says nothing
unless the "if" clause is true, which it is not in this case. If you
think it is, then, instead of hitchhiking on Rod, please explain how
it is. I cannot see the slightest resemblance myself.
On 8/3/05, Michael Jouravlev <jm...@gmail.com> wrote:
> http://www.theserverside.com/news/thread.tss?thread_id=35233
>
> If Rod Johnson have the same position on DTOs as me, should I be twice
> confident in my point of view? ;-)
>
> Michael.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
> For additional commands, e-mail: user-help@struts.apache.org
>
>
--
"You can lead a horse to water but you cannot make it float on its back."
~Dakota Jack~
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: DTOs are evil
Posted by Adam Hardy <ah...@cyberspaceroad.com>.
Rick Reumann on 04/08/05 19:12, wrote:
>> In particular, CRUD actions are not behaviour of the business object
>> ('save employee object to the database' is not an operation that makes
>> sense in the context of the business domain, it's an implementation
>> artifact [speaking broadly]). That's partly what makes them a good
>> candidate for encapsulating separately.
>
>
> I totally agree, yet this topic seems to come up a lot - where you'll
> see people state it's 'better design' and 'adheres more to standard OO'
> to do just the opposite (that is add these kind of CRUD methods to the
> object in question). I tend to agree that CRUD actions are NOT behaviors
> of business objects. For example, if working with "Dog" objects a "save"
> is much different than say "performBark()." Barking, moving, eating
> owner's shoes, are behavior of a Dog - I don't see CRUD in the same light.
If a dog must save itself when it changes but cannot have the action as
a behaviour, you immediately accept the necessity of a persistence
layer. Hence Hibernate, EJB CMP, etc and the DAO pattern.
So where does that leave the DTO? By my way of thinking (a dangerous
area indeed most likely) it is still very OO to have a class with
business methods, but where the data is encapsulated within the DTO,
which itself as a whole is a property or an item in a collection, rather
than a whole series of getters, setters and private properties.
But it's getting late so I'm willing to be proved wrong.
Adam
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: DTOs are evil
Posted by Rick Reumann <st...@reumann.net>.
Laurie Harper wrote the following on 8/4/2005 12:58 PM:
> Looking up lists of things is sort of a meta-concern; you're right,
> putting that on the Employee object would clutter things up, especially
> when you start needing more complex queries -- e.g.
> getEmployeesEligibleForPerformanceBonus() etc. Since these kinds of
> operations are a higher level concern (i.e. they aren't operations on
> employees but on the entire data class) they should typically live in a
> higher layer. That's often represented as a 'service' or 'manager' API,
> which also turns out to be a good place to put business-transaction type
> operations which also tend to cross-cut across multiple domain objects.
This is EXACTLY what I currently do and even use the term "Service"
since it makes sense to me. (I also use regular DTOs in the standard
way.. simply a POJO). I guess my question is more to those (Rod?) that
say DTOs are a bad idea since I think it makes sense to have them. For
example, as your description above you might have a method in a service
class that is: getEmployeesEligibleForPerformanceBonus() To me, it also
then makes sense to encapsulate other Employee related operations there
also including standard CRUD stuff. I find an application to become
confusing when operations start being handled in different layers (ie
some done from Service/Delegate classes, some called from the
ValueObject itself).
> OO generally talks about grouping behaviour and data together, so
> factoring out the properties into a separate object would be less OO
> than factoring out a sub-set of the behaviour (the CRUD actions).
True, my initial statement was poorly worded, what I meant, though, was
in regard to the DTO debate, once you do factor of the CRUD stuff you
are left with just your standard DTO, but the distinction you make is
noteworthy.
> In particular, CRUD actions are not behaviour of the business object ('save
> employee object to the database' is not an operation that makes sense in
> the context of the business domain, it's an implementation artifact
> [speaking broadly]). That's partly what makes them a good candidate for
> encapsulating separately.
I totally agree, yet this topic seems to come up a lot - where you'll
see people state it's 'better design' and 'adheres more to standard OO'
to do just the opposite (that is add these kind of CRUD methods to the
object in question). I tend to agree that CRUD actions are NOT behaviors
of business objects. For example, if working with "Dog" objects a "save"
is much different than say "performBark()." Barking, moving, eating
owner's shoes, are behavior of a Dog - I don't see CRUD in the same light.
--
Rick
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: DTOs are evil
Posted by Laurie Harper <la...@holoweb.net>.
Rick Reumann wrote:
> I do agree, though, with what others have said that DTOs/ValueObjects
> aren't really that OO. It's funny that the subject comes up because I
> was a late bloomer to the programming world (started about 6 years and
> was a waiter and science teacher before that:), and when I first started
> reading the Java books and then applying that to what I was
> reading/seeing in JSP projects I was on, the concepts did seem to conflict.
>
> What I mean is take the concept of an "Employee." In almost all web
> applications you see the EmployeeDTO being passed to the DAO...
>
> employeeDAO.updateEmployee( employee );
>
> From what I recall the real OO way would be...
>
> employee.update();
>
> and employee takes care of updating itself.
The idea of a DTO is to encapsulate the persistence logic so that it can be
independent of the model representation and business logic, and easily
replaceable. There's nothing saying you can't put an update() method on
your business objects and have it delegate to a DTO but you risk having an
explosion of data access methods on your business objects that way. Since
persistence is typically a quite separate concern from other domain logic,
it makes sense to separate it out.
> From an OO perspective I don't see a problem having an Employee object
> that has a DAO inside that takes care of persistence. I do have a couple
> questions though about OO design if this approach is used...
>
> 1) Where do you encapsulate getting Collections back of your objects?
> For example an Employee object has CRUD methods, but what about you when
> you need a List of Employees? Do you make an EmployeeList object that
> has methods getEmployees? Do you maybe just 'cheat' and add a getList or
> getEmployees method directly to the Employee object?
Looking up lists of things is sort of a meta-concern; you're right, putting
that on the Employee object would clutter things up, especially when you
start needing more complex queries -- e.g.
getEmployeesEligibleForPerformanceBonus() etc. Since these kinds of
operations are a higher level concern (i.e. they aren't operations on
employees but on the entire data class) they should typically live in a
higher layer. That's often represented as a 'service' or 'manager' API,
which also turns out to be a good place to put business-transaction type
operations which also tend to cross-cut across multiple domain objects.
> 2) It also seems a bit heavy to return Collections of pretty heavy
> objects. (Each Employee since it's not a simple VO could be a large
> object - although by large I just mean having a bunch of methods in it
> etc - I'm not so sure it would be large footprint-wise if just the
> properties were being filled in the case of a list - so bottom line is
> maybe the extra stuff in the object doesn't matter much?
It depends on how 'connected' your domain objects are. If an employee
references a manager and a manager contains a collection of reports and ...
then you need to care about how much of the object graph you load when you
load each employee. different persistence frameworks and ORM tools have
different ways of managing this. If you need most of the data stored on an
employee from the list, returning a list of employees makes sense. If you
only need a sub-set of the properties on each employee, returning an
intermediate representation of the specific data query will make more sense.
> Side note...
>
> 3) Even from an OO perspective, you always hear about encapsulating
> unique behaviors to make things reusable, so in a sense couldn't you
> consider the 'properties' of an Employee 'unique' or, if not the
> properties, the CRUD stuff is 'sort of' unique? If this is the case, you
> could make an argument for separating out the properties into another
> object (DTO/VO) separate?
OO generally talks about grouping behaviour and data together, so factoring
out the properties into a separate object would be less OO than factoring
out a sub-set of the behaviour (the CRUD actions). In particular, CRUD
actions are not behaviour of the business object ('save employee object to
the database' is not an operation that makes sense in the context of the
business domain, it's an implementation artifact [speaking broadly]).
That's partly what makes them a good candidate for encapsulating separately.
L.
--
Laurie, Open Source advocate, Java geek and novice blogger:
http://www.holoweb.net/laurie
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: DTOs are evil
Posted by Michael Jouravlev <jm...@gmail.com>.
On 8/4/05, Laurie Harper <la...@holoweb.net> wrote:
> Rick Reumann wrote:
> > Michael Jouravlev wrote the following on 8/3/2005 9:07 PM:
> >> http://www.theserverside.com/news/thread.tss?thread_id=35233
> > Just curious what are Rod's exact views on the DTO? I searched for DTOs
> > on that link you posted but only saw posts by other people.
>
> Mechael's referring to a throw-away one-liner about half way through the
> actual presentation (which is about an hour and a quarter long if you want
> to sit through it; it's not a bad introduction to the issues involved in
> handling persistence). Rod doesn't explain or justify his statement in the
> presentation.
To squeeze 60-something slides into 60 minutes, he should have been
prepared. I do not believe that this "throw away one-liner" was not
mentioned somewhere in his notes. But yes, he have not (yet) explained
this remark on TSS. Maybe it was a "hook" to have others talk about
presentation ;)
Michael.
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: DTOs are evil
Posted by Laurie Harper <la...@holoweb.net>.
Rick Reumann wrote:
> Michael Jouravlev wrote the following on 8/3/2005 9:07 PM:
>> http://www.theserverside.com/news/thread.tss?thread_id=35233
> Just curious what are Rod's exact views on the DTO? I searched for DTOs
> on that link you posted but only saw posts by other people.
Mechael's referring to a throw-away one-liner about half way through the
actual presentation (which is about an hour and a quarter long if you want
to sit through it; it's not a bad introduction to the issues involved in
handling persistence). Rod doesn't explain or justify his statement in the
presentation.
L.
--
Laurie, Open Source advocate, Java geek and novice blogger:
http://www.holoweb.net/laurie
---------------------------------------------------------------------
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
Re: [OT] DTOs are evil
Posted by Michael Jouravlev <jm...@gmail.com>.
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 Leon Rosenberg <st...@anotheria.net>.
> -----Ursprüngliche Nachricht-----
> Von: Michael Jouravlev [mailto:jmikus@gmail.com]
> 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: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: DTOs are evil
Posted by Laurie Harper <la...@holoweb.net>.
Michael Jouravlev wrote:
> On 8/4/05, Laurie Harper <la...@holoweb.net> wrote:
>>The idea of a DTO is to encapsulate the persistence logic so that it can be
>>independent of the model representation and business logic, and easily
>>replaceable.
>
> I thought that this is the idea of DAO.
Oops, typo, I meant DAO here of course.
>>There's nothing saying you can't put an update() method on
>>your business objects and have it delegate to a DTO but you risk having an
>>explosion of data access methods on your business objects that way. Since
>>persistence is typically a quite separate concern from other domain logic,
>>it makes sense to separate it out.
>
> This I agree with, moving persistence details to DAO is good. But DAO
> is not DTO ;-)
>
>>Looking up lists of things is sort of a meta-concern; you're right, putting
>>that on the Employee object would clutter things up, especially when you
>>start needing more complex queries -- e.g.
>>getEmployeesEligibleForPerformanceBonus() etc.
>
> If I remeber correctly, EJB encouraged practice like that.
yes, I'd say EJB popularized the pattern, at least in part due to the
course granularity of the call protocol in EJB 1.0.
>>Since these kinds of
>>operations are a higher level concern (i.e. they aren't operations on
>>employees but on the entire data class) they should typically live in a
>>higher layer.
>
> I would prefer other Rick's idea of having another business object
> like ListOfEmployess with different finders.
I prefer not to introduce objects like this in the domain model unless they
actually make sense as part of the business domain. In other words, if
there is an entity type 'collection of employees' (as a distinct entity,
not just as a collection property on some other entity) in the business
domain, it makes sense for that to be reflected in the model. If not, the
list object is in the application domain and I prefer to keep it in the
service layer instead of the domain layer.
>>OO generally talks about grouping behaviour and data together, so factoring
>>out the properties into a separate object would be less OO than factoring
>>out a sub-set of the behaviour (the CRUD actions). In particular, CRUD
>>actions are not behaviour of the business object ('save employee object to
>>the database' is not an operation that makes sense in the context of the
>>business domain, it's an implementation artifact [speaking broadly]).
>>That's partly what makes them a good candidate for encapsulating separately.
>
> Agree with that.
>
> I would like to return back to the objects. I still think, that a user
> works (at least wants to work) with objects, either with singletons or
> with sets of objects. Real-life objects (the ones the user wants to
> work with) are represented in the application, and OOP theory is all
> about representing real objects with app objects. So, if the modeling
> and representaion is done right, we do not need DTOs, because we
> already store objects that are of interest for a user.
Remember there's a distinction between 'we already model' and 'we already
store'. Also, DTOs are about transporting data from one layer to another,
i.e. as was pointed out elsewhere they're part of the API contract between
layers at least as much as they are a layer (or part thereof). Again, it's
a pattern popularized by EJB and the value DTOs provide gets less and less
clear the further you go from a course-grained, remote invocation call API.
Where I use them outside EJB is to create a distinction between the model
and the view; i.e. I use DTOs as 'view objects' which I pass into my JSPs
or whatever rather than passing the business objects directly. I know you,
and many others, dislike that practice though ;-) I do it so I have a place
to encapsulate view-specific logic, such as for example having a
UserDTO.getDisplayName() method which returns UserBO.getName() if set,
UserBO.getLoginId() if not.
> I can understand the idea of loading only 2 fields out of 20 or
> aggregating several objects into one, but I really would not care
> unless we loading a set of objects.
The key here is coding the application to optimize the database usage; if
you have an object with a lot of properties and/or references to and
collections of other objects and all you need to do is display a list of
their names, something that reduces to 'SELECT NAME FROM foo...' is going
to hit the database a lot less than something that pulls back all the data
associated with each instance.
> So, DTOs are useful where:
> * model was done incorrectly
> * in cases of really severe bandwidth contstraints
> * for sets (lists) of objects
>
> Now what if you have list of objects, and you create another one? If
> you use DTOs, you need to save DTO1 to database, and also to create
> and insert DTO2 in the list. If you had real object, you just create
> it, save it, and add to the list. One object instead of two. Of
> course, you can reread the list after you save the object, but this is
> unefficient, right?
I'm not sure I follow you here. Yes, as soon as you start using DTOs you
have the (minor) overhead of copying data between the DTOs and BOs. I the
application is simple enough, the benefits of using DTOs wont be enough to
justify the cost/complexity of that, but it's not a lot of cost/complexity
in most cases.
> On the other hand, application design is usually different for
> read-only and for read-write applications (classic OLAP vs. OLTP
> case).
Very true.
> I am for having persistence separate from business objects, but
> factored-out persistence still needs to build proper SQL statement
> depending on the object it saves... I am against putting validation
> outside of business objects. Validation rules belong to business
> objects, imho.
There's more than one type of validation, though. For example, BOs should
be typed so they should never have to worry about 'is this a valid date?'
or 'is this an integer?'. BOs should implement validation consistent with
business rules to maintain system invariants but it's often appropriate to
have other types of validation in the service and presentation layers.
L.
>
> On 8/4/05, Frank W. Zammetti <fz...@omnytex.com> wrote:
>
>>Then I had a special Action base class that worked against an XML file.
>>So, in keeping with my examples from before, you might see:
>>
>><action name="action1">
>> <function id="1">createDTO:ClientDTO</function>
>> <function id="2">copyActionForm:ClientDTO</function>
>> <function
>>id="3">callMethod:ClientHelper.isClientValid(ClientDTO)</function>
>> <check sourceid="3">
>> <if outcome="false">returnForward:clientnotvalid</if>
>> </check>
>> <function id="4">callMethod:ClientFB.saveClient(ClientDTO)</function>
>> <check sourceid="4">
>> <if outcome="true">returnForward:goodsave</if>
>> <if outcome="false">returnForward:badsave</if>
>> </check>
>></action>
>>
>>The createDTO, copyActionForm, callMethod and returnForward were standard
>>"commands" I could issue. I got it working to this point, never took the
>>exercise any further...
>
>
> Hmm, my CRUDAction does almost exactly the same, but it has predefined
> list of events (methods) and outcomes.
--
Laurie, Open Source advocate, Java geek and novice blogger:
http://www.holoweb.net/laurie
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: DTOs are evil
Posted by Michael Jouravlev <jm...@gmail.com>.
On 8/4/05, Laurie Harper <la...@holoweb.net> wrote:
> The idea of a DTO is to encapsulate the persistence logic so that it can be
> independent of the model representation and business logic, and easily
> replaceable.
I thought that this is the idea of DAO.
> There's nothing saying you can't put an update() method on
> your business objects and have it delegate to a DTO but you risk having an
> explosion of data access methods on your business objects that way. Since
> persistence is typically a quite separate concern from other domain logic,
> it makes sense to separate it out.
This I agree with, moving persistence details to DAO is good. But DAO
is not DTO ;-)
> Looking up lists of things is sort of a meta-concern; you're right, putting
> that on the Employee object would clutter things up, especially when you
> start needing more complex queries -- e.g.
> getEmployeesEligibleForPerformanceBonus() etc.
If I remeber correctly, EJB encouraged practice like that.
> Since these kinds of
> operations are a higher level concern (i.e. they aren't operations on
> employees but on the entire data class) they should typically live in a
> higher layer.
I would prefer other Rick's idea of having another business object
like ListOfEmployess with different finders.
> OO generally talks about grouping behaviour and data together, so factoring
> out the properties into a separate object would be less OO than factoring
> out a sub-set of the behaviour (the CRUD actions). In particular, CRUD
> actions are not behaviour of the business object ('save employee object to
> the database' is not an operation that makes sense in the context of the
> business domain, it's an implementation artifact [speaking broadly]).
> That's partly what makes them a good candidate for encapsulating separately.
Agree with that.
I would like to return back to the objects. I still think, that a user
works (at least wants to work) with objects, either with singletons or
with sets of objects. Real-life objects (the ones the user wants to
work with) are represented in the application, and OOP theory is all
about representing real objects with app objects. So, if the modeling
and representaion is done right, we do not need DTOs, because we
already store objects that are of interest for a user.
I can understand the idea of loading only 2 fields out of 20 or
aggregating several objects into one, but I really would not care
unless we loading a set of objects.
So, DTOs are useful where:
* model was done incorrectly
* in cases of really severe bandwidth contstraints
* for sets (lists) of objects
Now what if you have list of objects, and you create another one? If
you use DTOs, you need to save DTO1 to database, and also to create
and insert DTO2 in the list. If you had real object, you just create
it, save it, and add to the list. One object instead of two. Of
course, you can reread the list after you save the object, but this is
unefficient, right?
On the other hand, application design is usually different for
read-only and for read-write applications (classic OLAP vs. OLTP
case).
I am for having persistence separate from business objects, but
factored-out persistence still needs to build proper SQL statement
depending on the object it saves... I am against putting validation
outside of business objects. Validation rules belong to business
objects, imho.
On 8/4/05, Frank W. Zammetti <fz...@omnytex.com> wrote:
> Then I had a special Action base class that worked against an XML file.
> So, in keeping with my examples from before, you might see:
>
> <action name="action1">
> <function id="1">createDTO:ClientDTO</function>
> <function id="2">copyActionForm:ClientDTO</function>
> <function
> id="3">callMethod:ClientHelper.isClientValid(ClientDTO)</function>
> <check sourceid="3">
> <if outcome="false">returnForward:clientnotvalid</if>
> </check>
> <function id="4">callMethod:ClientFB.saveClient(ClientDTO)</function>
> <check sourceid="4">
> <if outcome="true">returnForward:goodsave</if>
> <if outcome="false">returnForward:badsave</if>
> </check>
> </action>
>
> The createDTO, copyActionForm, callMethod and returnForward were standard
> "commands" I could issue. I got it working to this point, never took the
> exercise any further...
Hmm, my CRUDAction does almost exactly the same, but it has predefined
list of events (methods) and outcomes.
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: DTOs are evil
Posted by "Frank W. Zammetti" <fz...@omnytex.com>.
On Thu, August 4, 2005 2:12 pm, Dave Newton said:
> Frank W. Zammetti wrote:
>
>>ArrayList getClientList();
>>ClientDTO getClientInfo(String id);
>>boolean saveClient(ClientDTO client);
>>boolean deleteClient(String id);
>
> (Hey, shouldn't getClientList return a List? ;)
Yep, I suppose it should :) I have a bad habit of specifying
implementations rather than interfaces for collections. Some day I'll
break myself of it :)
> I've never actually switched persistence mechanisms, of course, which
> leads me to wonder if I really need[ed] to do all that work. :/
I've yet to do it either, although I may have to with my most recent app.
I'm not really looking forward to it... I don't mind learning new stuff as
part of a new project, but retrofitting tends to be more annoying than
fun, for me anyway.
>>I even toyed at one point with the idea of doing all of the above from a
>>config file and reducing the app to a single specialized Action in most
>>places. When you find that most of your Actions look like the above,
>>that's a fairly appealing idea!
>>
>>
> That's actually where I'm headed right now for generic CMS/CRUD, but I'm
> getting bogged down.
>
> *sigh*
This kind of goes with the whole framework discussions around here
recently... this is the kind of thing I'd like to see in a new framework.
I think there are large chunks of most webapps that can be "developed" in
a purely declarative way, if the system is robust enough. I should only
have to write code for the more fringe cases (maybe not QUITE fringe
cases, but I think you know what I mean).
> Well, yes and no--Common Lisp implements its OO by using generic methods:
>
> (when (isValid cfbh cfb)
> (save cfb cdto))
>
> so you still write an isValid and a save for each useful combination of
> FB and FBHelpers, but methods are dispatchedd based on the types of the
> parameters. More or less the same as if you wrote a class like this:
>
> public class SortaGeneric {
> public static boolean isValid(ClientFBHelper cfbh_, ClientDTO cdto_) {
> // ... and then a miracle occurs
> return resultsOfClientDtoValidation;
> }
> public static boolean isValid(CompanyFBHelper cfbh_, CompanyDTO cdto_)
> {
> // ... you get the idea
> }
> }
>
> and did
>
> if (SortaGeneric.isValid(cfbh, cdto)) {
> if (SortaGeneric.save(cdto)) {
> }
> }
>
> but in Lisp you can define the generics in a more appropriate place than
> a non-local static method class.
>
> The only real difference between this and what you've done is the
> location of those methods--basically OO-by-hand rather than letting the
> system do it for you. With mild config and reflection you could remove
> the class depedencies in the actions, which is where my low-level stuff
> seems to be heading at the moment.
Interesting stuff! I like the comment about removing the class
dependencies from the Actions, that's really what my declarative version
did, at least as far as the proof-of-concept went... I added some config
elements to struts-config that allowed you to declare what FBs and
FBHelpers each Action needed. So, you might see:
<actionDependencies action="action1">
<object name="ClientFB">com.company.app.ClientFB</object>
<object name="ClientFBHelper">com.company.app.ClientFBHelper</object>
</actionDependencies>
So, in a sense, those dependencies were injected into the Action. You
just did the action work with them, everything else was handled outside.
Then I had a special Action base class that worked against an XML file.
So, in keeping with my examples from before, you might see:
<action name="action1">
<function id="1">createDTO:ClientDTO</function>
<function id="2">copyActionForm:ClientDTO</function>
<function
id="3">callMethod:ClientHelper.isClientValid(ClientDTO)</function>
<check sourceid="3">
<if outcome="false">returnForward:clientnotvalid</if>
</check>
<function id="4">callMethod:ClientFB.saveClient(ClientDTO)</function>
<check sourceid="4">
<if outcome="true">returnForward:goodsave</if>
<if outcome="false">returnForward:badsave</if>
</check>
</action>
The createDTO, copyActionForm, callMethod and returnForward were standard
"commands" I could issue. I got it working to this point, never took the
exercise any further... there were some obvious problems that would have
taken a bit more effort to solve, but more importantly I wasn't really
sure it was actually better... declarative over code is almost always true
for me, but there is a certain point where the declarative complexity
outweighs just writing the code. This might have been one of those cases,
I'm not sure :)
Even still, I think the idea is an interesting one, if done well.
Frank
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: DTOs are evil
Posted by Dave Newton <ne...@pingsite.com>.
Frank W. Zammetti wrote:
>ArrayList getClientList();
>ClientDTO getClientInfo(String id);
>boolean saveClient(ClientDTO client);
>boolean deleteClient(String id);
>
>In any case, only these FBs know anything about how the data is stored.
>
>
I do much the same thing defined as an interface so I can switch
persistence mechanisms.
(Hey, shouldn't getClientList return a List? ;)
I've never actually switched persistence mechanisms, of course, which
leads me to wonder if I really need[ed] to do all that work. :/
>I even toyed at one point with the idea of doing all of the above from a
>config file and reducing the app to a single specialized Action in most
>places. When you find that most of your Actions look like the above,
>that's a fairly appealing idea!
>
>
That's actually where I'm headed right now for generic CMS/CRUD, but I'm
getting bogged down.
*sigh*
>So, to Rick's original point, I guess this really isn't as OO as we all
>started out learning :)
>
Well, yes and no--Common Lisp implements its OO by using generic methods:
(when (isValid cfbh cfb)
(save cfb cdto))
so you still write an isValid and a save for each useful combination of
FB and FBHelpers, but methods are dispatchedd based on the types of the
parameters. More or less the same as if you wrote a class like this:
public class SortaGeneric {
public static boolean isValid(ClientFBHelper cfbh_, ClientDTO cdto_) {
// ... and then a miracle occurs
return resultsOfClientDtoValidation;
}
public static boolean isValid(CompanyFBHelper cfbh_, CompanyDTO cdto_) {
// ... you get the idea
}
}
and did
if (SortaGeneric.isValid(cfbh, cdto)) {
if (SortaGeneric.save(cdto)) {
}
}
but in Lisp you can define the generics in a more appropriate place than
a non-local static method class.
The only real difference between this and what you've done is the
location of those methods--basically OO-by-hand rather than letting the
system do it for you. With mild config and reflection you could remove
the class depedencies in the actions, which is where my low-level stuff
seems to be heading at the moment.
Dave
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
RE: DTOs are evil
Posted by "Frank W. Zammetti" <fz...@omnytex.com>.
I too have taken something of a hybrid approach in most cases...
I created something called a Function Bean (FB), which for all intents and
purposes is really just a DAO. For instance, in one app I have a ClientFB
class that has methods like:
ArrayList getClientList();
ClientDTO getClientInfo(String id);
boolean saveClient(ClientDTO client);
boolean deleteClient(String id);
All the typical methods... note that the DTOs are really only for data
storage and transpot... there are usually no operations attached (except
sometimes for simple things like comparisons and such).
In any case, only these FBs know anything about how the data is stored.
Then I have a ClientFBHelper class that is where the actual business
logic-type things reside, so that the ClientFB winds up just dealing with
persistance. So, in it I might have:
boolean isClientValid(ClientDTO client);
Where it starts to become a little bit of a hybrid is that the FBs don't
actually, in many cases, map to real modeled objects. I'd describe them
as more mapping to a view of the model.
So in my Actions I do things like (in the case of saving a client):
ClientFB cfb = fbfactory.get("ClientFB");
ClientFBHelper cfbh = fbhelperfacroty.get("ClientFBHelper");
ClientDTO cdto = new ClientDTO();
PropertyUtils.copyProperties(cdto, actionform);
ActionForward af;
if (cfbh.isClientValid(cdto)) {
if (cfb.saveClient(cdto)) {
af = mapping.findForward("goodsave");
} else {
af = mapping.findForward("badsave");
}
} else {
af = mapping.findForward("notvalid");
}
return af;
The FBs and FBHelpers are gotten from a factory only, so I can control
various things easily (i.e., the factory makes sure the beans get set up
in the beginning and cleaned up at the end, share a database connection if
need be, things like that). There is actually a Struts base Action that
instantiates the factories and passes them into execute() and then cleans
them up afterwards, but that's kind of outside this particular discussion.
I even toyed at one point with the idea of doing all of the above from a
config file and reducing the app to a single specialized Action in most
places. When you find that most of your Actions look like the above,
that's a fairly appealing idea!
The nice thing about this setup is that I can test the persistance in the
FBs separate from the application and the helper classes separate from the
FBs and the app, etc. It's also trivially easy to mock up either to test
the app.
In this approach, you can have a persistence framework involved or not.
We've only recently here decided to use Hibernate across-the-board, so
much of our existing apps are straight JDBC. But, converting them to use
Hibernate will only require changes in the FBs, everything else remains
the same (I've done some pilots to test that theory, and it works out
nicely).
So, to Rick's original point, I guess this really isn't as OO as we all
started out learning :) But, as with most things it's an evolution of
understanding... I'd be willing to bet that 5 years from now we won't be
writing apps like we do today either and we'll wonder why we ever did
things this way or that.
--
Frank W. Zammetti
Founder and Chief Software Architect
Omnytex Technologies
http://www.omnytex.com
On Thu, August 4, 2005 12:05 pm, Mark Benussi said:
> That's how my persistence framework goes.
>
> All my data extends a data object which makes public CRUD methods that
> accept a persister, you can then have File persisters, Database persisters
> etc. An employee shouldn't have any knowledge of how they persist in an
> enterprise IMHO. All that logic is placed in the persister.
>
> Employee employee = new Employee();
> employee.setKey(1);
>
> // Reads and populates an employee.
> EmployeeDBPersister dbPersister = new EmployeeDBPersister(conn);
> employee.read(dbPersister);
>
> // Writes the employee to a file.
> EmployeeFilePersister filePersister = new EmployeeFilePersister(file);
> employee.create(filePersister);
>
> I hate DAO's. The company I work for uses them. Basically one class to do
> all the logic related in any way shape of form to a valgue amount of
> database tables. They then change a column on a table and wonder why there
> code is a nightmare to fix. If you have one Persister responsible for a
> table then you change the four pieces of sql for create read update and
> delete and you are laughing.
>
> In answer to the collections comment, I have managers which my application
> interfaces with to get collections. Basically something like
>
> EmployeeManager manager = new EmployeeManager();
> ArrayList employees = manager.getEmployees();
>
> And the method gets all the keys in a separate piece of SQL and then calls
> the code I have shown above.
>
> -----Original Message-----
> From: Rick Reumann [mailto:struttin@reumann.net]
> Sent: 04 August 2005 16:15
> To: Struts Users Mailing List
> Subject: Re: DTOs are evil
>
> Michael Jouravlev wrote the following on 8/3/2005 9:07 PM:
>> http://www.theserverside.com/news/thread.tss?thread_id=35233
>>
>
> Just curious what are Rod's exact views on the DTO? I searched for DTOs
> on that link you posted but only saw posts by other people.
>
> I do agree, though, with what others have said that DTOs/ValueObjects
> aren't really that OO. It's funny that the subject comes up because I
> was a late bloomer to the programming world (started about 6 years and
> was a waiter and science teacher before that:), and when I first started
> reading the Java books and then applying that to what I was
> reading/seeing in JSP projects I was on, the concepts did seem to
> conflict.
>
> What I mean is take the concept of an "Employee." In almost all web
> applications you see the EmployeeDTO being passed to the DAO...
>
> employeeDAO.updateEmployee( employee );
>
> From what I recall the real OO way would be...
>
> employee.update();
>
> and employee takes care of updating itself.
>
> From an OO perspective I don't see a problem having an Employee object
> that has a DAO inside that takes care of persistence. I do have a couple
> questions though about OO design if this approach is used...
>
> 1) Where do you encapsulate getting Collections back of your objects?
> For example an Employee object has CRUD methods, but what about you when
> you need a List of Employees? Do you make an EmployeeList object that
> has methods getEmployees? Do you maybe just 'cheat' and add a getList or
> getEmployees method directly to the Employee object?
>
> 2) It also seems a bit heavy to return Collections of pretty heavy
> objects. (Each Employee since it's not a simple VO could be a large
> object - although by large I just mean having a bunch of methods in it
> etc - I'm not so sure it would be large footprint-wise if just the
> properties were being filled in the case of a list - so bottom line is
> maybe the extra stuff in the object doesn't matter much?
>
> Side note...
>
> 3) Even from an OO perspective, you always hear about encapsulating
> unique behaviors to make things reusable, so in a sense couldn't you
> consider the 'properties' of an Employee 'unique' or, if not the
> properties, the CRUD stuff is 'sort of' unique? If this is the case, you
> could make an argument for separating out the properties into another
> object (DTO/VO) separate?
>
>
> --
> Rick
>
> ---------------------------------------------------------------------
> 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
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
RE: DTOs are evil
Posted by Mark Benussi <ma...@hotmail.com>.
That's how my persistence framework goes.
All my data extends a data object which makes public CRUD methods that
accept a persister, you can then have File persisters, Database persisters
etc. An employee shouldn't have any knowledge of how they persist in an
enterprise IMHO. All that logic is placed in the persister.
Employee employee = new Employee();
employee.setKey(1);
// Reads and populates an employee.
EmployeeDBPersister dbPersister = new EmployeeDBPersister(conn);
employee.read(dbPersister);
// Writes the employee to a file.
EmployeeFilePersister filePersister = new EmployeeFilePersister(file);
employee.create(filePersister);
I hate DAO's. The company I work for uses them. Basically one class to do
all the logic related in any way shape of form to a valgue amount of
database tables. They then change a column on a table and wonder why there
code is a nightmare to fix. If you have one Persister responsible for a
table then you change the four pieces of sql for create read update and
delete and you are laughing.
In answer to the collections comment, I have managers which my application
interfaces with to get collections. Basically something like
EmployeeManager manager = new EmployeeManager();
ArrayList employees = manager.getEmployees();
And the method gets all the keys in a separate piece of SQL and then calls
the code I have shown above.
-----Original Message-----
From: Rick Reumann [mailto:struttin@reumann.net]
Sent: 04 August 2005 16:15
To: Struts Users Mailing List
Subject: Re: DTOs are evil
Michael Jouravlev wrote the following on 8/3/2005 9:07 PM:
> http://www.theserverside.com/news/thread.tss?thread_id=35233
>
Just curious what are Rod's exact views on the DTO? I searched for DTOs
on that link you posted but only saw posts by other people.
I do agree, though, with what others have said that DTOs/ValueObjects
aren't really that OO. It's funny that the subject comes up because I
was a late bloomer to the programming world (started about 6 years and
was a waiter and science teacher before that:), and when I first started
reading the Java books and then applying that to what I was
reading/seeing in JSP projects I was on, the concepts did seem to conflict.
What I mean is take the concept of an "Employee." In almost all web
applications you see the EmployeeDTO being passed to the DAO...
employeeDAO.updateEmployee( employee );
From what I recall the real OO way would be...
employee.update();
and employee takes care of updating itself.
From an OO perspective I don't see a problem having an Employee object
that has a DAO inside that takes care of persistence. I do have a couple
questions though about OO design if this approach is used...
1) Where do you encapsulate getting Collections back of your objects?
For example an Employee object has CRUD methods, but what about you when
you need a List of Employees? Do you make an EmployeeList object that
has methods getEmployees? Do you maybe just 'cheat' and add a getList or
getEmployees method directly to the Employee object?
2) It also seems a bit heavy to return Collections of pretty heavy
objects. (Each Employee since it's not a simple VO could be a large
object - although by large I just mean having a bunch of methods in it
etc - I'm not so sure it would be large footprint-wise if just the
properties were being filled in the case of a list - so bottom line is
maybe the extra stuff in the object doesn't matter much?
Side note...
3) Even from an OO perspective, you always hear about encapsulating
unique behaviors to make things reusable, so in a sense couldn't you
consider the 'properties' of an Employee 'unique' or, if not the
properties, the CRUD stuff is 'sort of' unique? If this is the case, you
could make an argument for separating out the properties into another
object (DTO/VO) separate?
--
Rick
---------------------------------------------------------------------
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: DTOs are evil
Posted by Daniel Perry <d....@netcase.co.uk>.
> employeeDAO.updateEmployee( employee );
>
> From what I recall the real OO way would be...
>
> employee.update();
>
> and employee takes care of updating itself.
>
I made a BaseBO using OJB, which has the create, update, softDelete,
hardDelete, findById, findByCriteria methods. It also has an id and deleted
fields.
Any other BOs extend it, and inherit the behaviours. The only tie to OJB in
any class other than BaseBO is the Criteria and QueryByCriteria classes
which are used for any queries other than findById, which i cant see a way
round.
The only downside is writing the mappings for each class (though this can be
simplified using XDoclet).
It works wonderfully, and saved lots of coding.
Daniel.
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: DTOs are evil
Posted by Rick Reumann <st...@reumann.net>.
Michael Jouravlev wrote the following on 8/3/2005 9:07 PM:
> http://www.theserverside.com/news/thread.tss?thread_id=35233
>
Just curious what are Rod's exact views on the DTO? I searched for DTOs
on that link you posted but only saw posts by other people.
I do agree, though, with what others have said that DTOs/ValueObjects
aren't really that OO. It's funny that the subject comes up because I
was a late bloomer to the programming world (started about 6 years and
was a waiter and science teacher before that:), and when I first started
reading the Java books and then applying that to what I was
reading/seeing in JSP projects I was on, the concepts did seem to conflict.
What I mean is take the concept of an "Employee." In almost all web
applications you see the EmployeeDTO being passed to the DAO...
employeeDAO.updateEmployee( employee );
From what I recall the real OO way would be...
employee.update();
and employee takes care of updating itself.
From an OO perspective I don't see a problem having an Employee object
that has a DAO inside that takes care of persistence. I do have a couple
questions though about OO design if this approach is used...
1) Where do you encapsulate getting Collections back of your objects?
For example an Employee object has CRUD methods, but what about you when
you need a List of Employees? Do you make an EmployeeList object that
has methods getEmployees? Do you maybe just 'cheat' and add a getList or
getEmployees method directly to the Employee object?
2) It also seems a bit heavy to return Collections of pretty heavy
objects. (Each Employee since it's not a simple VO could be a large
object - although by large I just mean having a bunch of methods in it
etc - I'm not so sure it would be large footprint-wise if just the
properties were being filled in the case of a list - so bottom line is
maybe the extra stuff in the object doesn't matter much?
Side note...
3) Even from an OO perspective, you always hear about encapsulating
unique behaviors to make things reusable, so in a sense couldn't you
consider the 'properties' of an Employee 'unique' or, if not the
properties, the CRUD stuff is 'sort of' unique? If this is the case, you
could make an argument for separating out the properties into another
object (DTO/VO) separate?
--
Rick
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org