I've read a lot of posts but i can't take a decission about use dtos or bussiness objects in GUI layer.

My layered arquitecture is like this :

Front End GUI : Swing / Struts
Service Layer : Stateless ejbs / Soap
Domain Layer : POJOS
DAO Layer : Spring support

I think the use of dtos disacouple the service layer from the domain Model. However it's necessary a lot of work to get it.

I need a solution to pass data to swing from the Service Layer to GUI.
I'd like experiences from people who use a domain model of 50 classes with a lot of relations, with a lot of data.


Thank you.

No DTO. My domain model is independant from any other layer and is corss layer. This is for sure a *real* code reuse

... and your "domain model" is just a bunch of simple structures ... ;)

Certainly not. I'm not paid to write tutorials

Some will tell you to never use DTOs. For me it really comes down to usage (personally, I rarely come across hard-and-fast rules reagrding programming approaches, but to each his own).

In general, the conclusion I've come to is that if you have control over all aspects of the intended application's deployment and usage then using the domain entities mapped in Hibernate to broker data to the UI is a valid approach. If, however, you intended something where these objects make up an API that is exposed to usages outside of your control, then I would think twice before taking this approach (mainly due to lazy initialization issues).

Steve, I think like you.

I belive that if I have a web application whose API will not be used, I can use domain objects to render the data. However if I want create a API to access the application services I should create DTOs for the data transfer. But I was not sure that this was correct, due to all posts I've read.

About the DTO, anybody use dynamic DTOs created using HashMap or use beans?

Having DTOs created with HashMap reduce the number of classes in my system. However I think that is clear use beans.

Not quite what I was saying. If your or your team control the usage of this API (i.e., if it will not be accessed by others outside your team), then its still ok to use the domain entities directly through the API.

Personally I'd use the JavaBean approach, but admittedly this is a pain in the a** with all the parallel classes...

hi all,
just to remeber:
http://forum.hibernate.org/viewtopic.ph ... hlight=dto

in my case the problem is about the project organisation.
In my society we start thinking the UI layer with users (clients), so when all is validated, we have the jsp but no domain model (it comes later).

The development team may sometimes start coding jsp before having a domain model. For this we need DTO (not to rework all the jsp when domain model is validated).
I know this is not the best project organisation, but we must do with it.
We have coded a PojoDTOCopier.
The idea is pretty simple and based on DynaBean.
We have another mapping file set in which we find
DTO.property = Pojo.property
It can support complex graph of objects since it has partially the same structure as an hbm file.
We're gonna bench this solution and compare both static pojo and dynamic pojo solution with loadrunner.

What is sure is that static or dynamic DTO is hell to manage and is not a code reuse since it is linked to the ui.


Anthony