Here is the general notes on when a DTO is needed:
Every method call made to the business service object, be it an entity
bean or a session bean, is potentially remote. Thus, in an Enterprise
JavaBeans (EJB) application such remote invocations use the network
layer regardless of the proximity of the client to the bean, creating
a network overhead. Enterprise bean method calls may permeate the
network layers of the system even if the client and the EJB container
holding the entity bean are both running in the same JVM, OS, or
physical machine. Some vendors may implement mechanisms to reduce this
overhead by using a more direct access approach and bypassing the
network.
As the usage of these remote methods increases, application
performance can significantly degrade. Therefore, using multiple calls
to get methods that return single attribute values is inefficient for
obtaining data values from an enterprise bean.
Forces
*
All access to an enterprise bean is performed via remote
interfaces to the bean. Every call to an enterprise bean is
potentially a remote method call with network overhead.
* Typically, applications have a greater frequency of read
transactions than update transactions. The client requires the data
from the business tier for presentation, display, and other read-only
types of processing. The client updates the data in the business tier
much less frequently than it reads the data.
* The client usually requires values for more than one attribute
or dependent object from an enterprise bean. Thus, the client may
invoke multiple remote calls to obtain the required data.
* The number of calls made by the client to the enterprise bean
impacts network performance. Chattier applications-those with
increased traffic between client and server tiers-often degrade
network performance.
Solution
Use a Transfer Object to encapsulate the business data. A single
method call is used to send and retrieve the Transfer Object. When the
client requests the enterprise bean for the business data, the
enterprise bean can construct the Transfer Object, populate it with
its attribute values, and pass it by value to the client.
Clients usually require more than one value from an enterprise bean.
To reduce the number of remote calls and to avoid the associated
overhead, it is best to use this pattern.
On Mon, 28 Feb 2005 15:22:28 +0000, Tim Christopher
<[EMAIL PROTECTED]> wrote:
> So what you're saying is that if I include a separate DTO it doesn't
> really achieve anything extra - whilst at the same time creating more
> code to maintain and reducing performance?
>
> Do you know if there is a formal writeup of what is in the blog,
> something article in a book / report or on a different web site -
> Google wasn't much help :-(
>
> Tim Christopher
>
> On Sun, 27 Feb 2005 16:26:35 -0500, Mike Millson
> <[EMAIL PROTECTED]> wrote:
> > On Sat, 2005-02-26 at 11:26, Tim Christopher wrote:
> > >
> > > I'm also a little concerned that my domain object (Customer.java) is
> > > also my DTO - is this good practice?
> >
> > Take a look at the following article:
> > http://www.javaperformancetuning.com/news/roundup050.shtml
> >
> > I think the author makes a good point. Having a separate DTO class is
> > like domain persistence, a very odd concept to me. I agree w/ the
> > author. Pass the domain object as the DTO, not a separate DTO class.
> >
> > Mike
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
--
"You can lead a horse to water but you cannot make it float on its back."
~Dakota Jack~
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
