On Thu, 2005-08-04 at 17:05 -0700, Michael Jouravlev wrote:
> On 8/4/05, Leon Rosenberg <[EMAIL PROTECTED]> wrote:
> > Each software system (which is large enough...) has more then one layer.
> > Different layers usually handles same data. Each of the layers has ist own
> > view on the data. The business layer, which has to calculate the salary of
> > an employee is not interested in employee's persistence capabilities. It's
> > not interested in internal object id (like the one generated by hibernate).
> > The presentation layer is not interested in employee's identity card
> > attribute, but solely in presentation issues, like name or similar.
> > According to the principles of data hiding, a layer should only be able to
> > access data, which it really needs. Therefore, there is no need that the
> > employee object which is used by the presentation layer is the same, which
> > is used by the business layer, and the same which knows everything about
> > underlying persistence capabilities, like oodb, rdb or file system.
>
> The employee object is employee object, it is the representation of a
> real-life object. The view of employee object can be different. That
> is what DTO is, it is a view.
> > Therefore the DTO object is the protocol, the language spoken between the
> > layers, and if you want to achieve a layer separation, you need to separate
> > the view from the data. (Olympic ring metaphor by Ted Husted).
>
> You mean, separate view from the business object, not from the data?
> ;-) Anyway, I am not sure that this separation is needed, unless view
> layer is developed by an evil third party contractor.
I give you a RL example. We have a relative large portal here, with some
10.000 classes and thousands of requests pro second, with large
databases in the back etc.
Our development environment contains at least 3 server for each test
cycle (unstable, stable-develop, integration, test). So it's about 12
machines you need as developer. Still I like to work at home from time
to time. I can't afford having 12 high-end machines at home. Instead we
have alternative implementations for all persistence layers, which go to
inmemory dbs or filesystems instead of real dbs. The business layer is
the same. We only switch the persistence layer and as by magic, it all
runs on my notebook. If my business object would encapsulate this
knowledge, i wouldn't be able to do this. But as we are
component-oriented we switch complete components. It wouldn't be
possible without DTOs.
>
> > You may say that the DTO's are not OO, because they only contain state and
> > no behaviour. That's right, but com'on, we are talking about java here, and
> > java isn't a simple OO language, but a component-oriented language, and DTOs
> > are part of the component definition.
> >
> > As for Rod Johnson, he said that DTOs are evil if you don't want to
> > distribute the application (arguable point btw, because i believe we should
> > provide clean application design in any case), but as I said before, we are
> > talking about _LARGE_SYSTEMS and they are 99% distributed.
>
> Rod (or what is Craig or David? I think it was Rod) said that by his
> assessment, only about 15% of EJB apps are distributed. All other guys
> simply spent hundreds of man-hours to make app distributable, for no
> reason. I do not think that this percentage is higher for non-EJB
> apps. What is really needed for distributed apps is Serializable
> objects.
Yes Rod said only 15% of EJB apps are distributed. But this was a critic
on EJB, since in EJB you have to decide early, if you distribute or not.
If you have a transparent middleware layer, which allows you to develop
monolithic and run distributed you don't care about it. We have such a
middleware, CORBA is such a middleware and Spring offers similar
mechanism too. You have to care about good coding style, like submitting
return values in hashmaps given as in-parameters will not work
distributed, but you wouldn't do it either way, right?
As for the Serializable -> you know something slower then that? I don't.
If you are playing around, you can distribute with serializable and RMI,
sure thing. If you need performance - forget it.
> >
> > P.S. By the way, Rod Johnson also said persistent objects that contain only
> > getters and setters are evil too (same page as dto, 27). In my understanding
> > it means hibernate and ibatis which use such objects are at least as evil?
> > How are you supposed to represent data anyway then?
>
> If getters and setters do nothing more than simply read field or set
> field, then they are evil, you do not need Rod Johnson to tell you
> that ;) Problem with Java that it got a lot of new stuff in 1.5, but
> it still does not have normal properties like Delphi has or at least
> like C# has. If a class member could have different access modifiers
> for read and write, then getters and setters would not be needed in
> most of cases.
> Delphi properties rule, Java getters/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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
