This week's book giveaway is in the Mac OS forum.
We're giving away four copies of a choice of "Take Control of Upgrading to Yosemite" or "Take Control of Automating Your Mac" and have Joe Kissell on-line!
See this thread for details.
The moose likes OO, Patterns, UML and Refactoring and the fly likes domain objects as DTO's Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


JavaRanch » Java Forums » Engineering » OO, Patterns, UML and Refactoring
Bookmark "domain objects as DTO Watch "domain objects as DTO New topic
Author

domain objects as DTO's

manish ahuja
Ranch Hand

Joined: Oct 23, 2003
Posts: 312
Hi there,

We are trying to follow a domain driven design approach. One question which cropped up is when we model domain concepts as distinct classes and have all the business logic part of it.
Say we have a domain concept like Customer and there can be 3 different types of Customer (TypeACustomer, TypeBCustomer, TypeCCustomer). So each of these classes will consist of business methods specific to the respective type and no common processor class having bunch of if-else logic jumping between blocks related to these types.

Now the instances of these Customer types don't originate in the application but are exposed to external apps which initialize the instances of these types and pass it to the application.
My question is it a common practice to expose the domain class instances as input/output data transfer objects also.
Since they contain all business logic should they be hidden from the external entities. If yes how is the separation normally/popularly achieved.

Thanks.
Jeanne Boyarsky
author & internet detective
Marshal

Joined: May 26, 2003
Posts: 30585
    
154

Manish,
DTOs are usually dumb objects that are used just for transfering data. If it has business logic, it's not a DTO by definition. This doesn't mean you can't use it to transfer data though.

I would use a real DTO if passing it outside the application. Just to minimize the impact when the business rules change.


[Blog] [JavaRanch FAQ] [How To Ask Questions The Smart Way] [Book Promos]
Blogging on Certs: SCEA Part 1, Part 2 & 3, Core Spring 3, OCAJP, OCPJP beta, TOGAF part 1 and part 2
Hong Anderson
Ranch Hand

Joined: Jul 05, 2005
Posts: 1936
Well, at first it would be nice to clarify that we would use DTO only if we have remote interfaces.
If we don't use remote interfaces, just don't use DTO, end of story.

DTO has nothing to do with any business rule, its main purpose is to reduce number of remote calls.
I mean they are not supposed to minimize impacts when business rules have changed, that is just not the purpose of this pattern.

To the topic creator, I'm not sure I fully understand what you want to do, could you please to give an example?


SCJA 1.0, SCJP 1.4, SCWCD 1.4, SCBCD 1.3, SCJP 5.0, SCEA 5, SCBCD 5; OCUP - Fundamental, Intermediate and Advanced; IBM Certified Solution Designer - OOAD, vUML 2; SpringSource Certified Spring Professional
Ilja Preuss
author
Sheriff

Joined: Jul 11, 2001
Posts: 14112
Kengkaj Sathianpantarit wrote:
DTO has nothing to do with any business rule, its main purpose is to reduce number of remote calls.
I mean they are not supposed to minimize impacts when business rules have changed, that is just not the purpose of this pattern.


Exactly. More specifically, their purpose is to transfer data in one single object (the DTO) that otherwise we would have to be transfer a whole number of Business Objects for.

If you want to reduce coupling between your application and external applications (which you probably should), you can use factories and interfaces instead. That way, the external applications can create and pass in your Business Objects without even knowing.


The soul is dyed the color of its thoughts. Think only on those things that are in line with your principles and can bear the light of day. The content of your character is your choice. Day by day, what you do is who you become. Your integrity is your destiny - it is the light that guides your way. - Heraclitus
manish ahuja
Ranch Hand

Joined: Oct 23, 2003
Posts: 312
Well I was not saying having business logic in DTO's.

What i was trying to imply is to have a class for each domain concept type. TypeACustomer, TypeBCustomer etc
So all specific attributes will reside in these respective classes. The business logic for the same will also be contained in these classes.

Now the way the instances of the aforementioned domain classes get populated is by an external app. So should we be maintaining a separate DTO layer just as mere data containers and then pass on to the domain classes or I can use the domain classes (TypeACustomer, TypeBCustomer etc) as data containers.

Manish
Hong Anderson
Ranch Hand

Joined: Jul 05, 2005
Posts: 1936
What you mean by "domain classes get populated is by an external app"?
You mean an external app instantiates domain objects or you mean something else?

How does your application communicate with this external app? You use Socket, RMI, Web Services, JMS or something?
Please give more information.
manish ahuja
Ranch Hand

Joined: Oct 23, 2003
Posts: 312
There are two types of external apps. One is pure java client app and the other is a web service.

The external app has to provide input data. So there are two options 1) expose dumb dto container objects which will be populated by the external apps and appropriate app functionality invoke passing in the dto's. The application functionality unwraps the dto and passes the input to specific business logic handlers which pass them down to domain objects (actual business logic processors).

option2) expose the domain object to the client apps. Now this domain object actually comprises the business logic too.

I would like to know your thoughts on this as I feel I can avoid the extra dto layer or the better approach in this type of scenario.

Thanks- Manish

Hong Anderson
Ranch Hand

Joined: Jul 05, 2005
Posts: 1936
manish ahuja wrote:
option2) expose the domain object to the client apps. Now this domain object actually comprises the business logic too.

If you mean remote interface and you want to reduce remote calls, using DTO is a good option.
If the client apps invoke a method on the domain object, it will call remote method on the server, because processing must happen on the server-side. You understand this right?
Ilja Preuss
author
Sheriff

Joined: Jul 11, 2001
Posts: 14112
Kengkaj Sathianpantarit wrote:
manish ahuja wrote:
option2) expose the domain object to the client apps. Now this domain object actually comprises the business logic too.

If you mean remote interface and you want to reduce remote calls, using DTO is a good option.
If the client apps invoke a method on the domain object, it will call remote method on the server, because processing must happen on the server-side. You understand this right?


That's not necessarily true. If the functionality in the domain object is self-contained (that is, it doesn't need other server functionality), the DO could just be serializable and the business logic executed on client side.
Ilja Preuss
author
Sheriff

Joined: Jul 11, 2001
Posts: 14112
There is possibly a third option, as I tried to say above: only expose interfaces to the client. That's especially simple if the client is actually running in the same JVM.
Hong Anderson
Ranch Hand

Joined: Jul 05, 2005
Posts: 1936
Ilja Preuss wrote:
Kengkaj Sathianpantarit wrote:
manish ahuja wrote:
option2) expose the domain object to the client apps. Now this domain object actually comprises the business logic too.

If you mean remote interface and you want to reduce remote calls, using DTO is a good option.
If the client apps invoke a method on the domain object, it will call remote method on the server, because processing must happen on the server-side. You understand this right?


That's not necessarily true. If the functionality in the domain object is self-contained (that is, it doesn't need other server functionality), the DO could just be serializable and the business logic executed on client side.

In sever-client applications, it's very rare for the client to be able to execute business logic on its own. Even in that case it is strange that why the server needs to send a domain object to the client, the server can send just a command String (or any kind of data the client can parse), and the client can create domain object and execute a method on its side. So no need to send an object.
Hong Anderson
Ranch Hand

Joined: Jul 05, 2005
Posts: 1936
Actually, I was not so sure, what the topic creator really wanted. So I repeated many times that TO/DTO is for reducing networks calls.

Ilja Preuss wrote:There is possibly a third option, as I tried to say above: only expose interfaces to the client. That's especially simple if the client is actually running in the same JVM.

Just to clarify, this is not true in the case of using Entity Beans, even if the client and the bean are in the same JVM, the remote invocations still use network layer.
Ilja Preuss
author
Sheriff

Joined: Jul 11, 2001
Posts: 14112
Kengkaj Sathianpantarit wrote:
In sever-client applications, it's very rare for the client to be able to execute business logic on its own.


Well, I'm actually working on exactly such an application. Don't care how rare it is - it's a valid option.

Even in that case it is strange that why the server needs to send a domain object to the client, the server can send just a command String (or any kind of data the client can parse), and the client can create domain object and execute a method on its side. So no need to send an object.


I don't understand the differentiation you are making. A serialized object is nothing more than data the client can parse. Only that the parsing (and serialization) is taken care of by the Java platform.

So, asked the other way around: why invest into dealing with sending command strings or parsing data and creating domain objects out of it, if you can just send an object?
Hong Anderson
Ranch Hand

Joined: Jul 05, 2005
Posts: 1936
Ilja Preuss wrote:
Kengkaj Sathianpantarit wrote:Even in that case it is strange that why the server needs to send a domain object to the client, the server can send just a command String (or any kind of data the client can parse), and the client can create domain object and execute a method on its side. So no need to send an object.


I don't understand the differentiation you are making. A serialized object is nothing more than data the client can parse. Only that the parsing (and serialization) is taken care of by the Java platform.

So, asked the other way around: why invest into dealing with sending command strings or parsing data and creating domain objects out of it, if you can just send an object?

The different is if we send a command string we can send only data that is necessary, on the other hand sending a domain object means sending unnecessary data like class definition.

For example if we have a domain object of the following class:

In case the client just want data, the server can send a string like {"prop1":100,"prop2":200} rather than an serialized Java object which contain unnecessary class definition. This is better in terms of data size, it can improve performance in case there are many communications between the server and the clients.

Sending string is also more flexible in case we want to support non-Java clients.
Ilja Preuss
author
Sheriff

Joined: Jul 11, 2001
Posts: 14112
No, the class definition is typically *not* sent when serialize an object. Just the object's data, and some metadata.
Hong Anderson
Ranch Hand

Joined: Jul 05, 2005
Posts: 1936
The serialized object will contain qualified class name and attribute metadata. Actually, this is minor point.
If the size of data is not very important or the application supports only Java clients, sending serialized Java objects is fine.

The another advantage of sending only data is we can design domain object class in client and server independently. For example, we can have business methods specific to client side in DomainObjectClient, and we can have business methods specific to server side in DomainObject (or DomainObjectServer).

But in case that all of business methods in DomainObject can be executed meaningfully in both client side and server side, sending domain objects from the server to the client is fine.
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: domain objects as DTO's