Hi. I have a model layer written with hibernate, and I have for example entities



and I want to have a web tier independet to the business code, so I don't open a session for the request to avoid hibernate code there. Instead, I open the session in each method in the model layer.

Now, i want to render table in the web tier with atributes ClassA.name, ClassB.someString. I'd like to ask what is the best practics to do this. Should I have a data trasfer object for each such table with the attributes of several entities?
The example with two classes I wrote is pretty simple, but I can have many classes or collections lazily fetched this way.

I hope i didn't describe the problem too confusedly to understand..

I would use the model entities as detached objects in the web view and let your business classes ensure, that the proxies are fully initialized with Hibernate.iniitialize(Object o). I always try to avoid DTOs as these lead to duplicated code. But of course, in some environments, they are necessary, for example, if the web tier resides on a different machine and cannot directly use the model entities.

Hi kaiec
I'm using the same architecture:

JSP -> Struts -> Busines Objects (business logic) -> DTOs -> DAOs -> Hibernate -> Oracle

So I'm using DTOs to transfer data among layers... The DAO layer is responsible for converting Hibernate POJOs to TOs, of course it has a performance cost, but not very high.

I choose this way of doing things 'cause I didn't want business tier to know anything about persistence tier. So I would change hibernate to another persistence mechanism without changing any logic.
The view tier doesn't know anything about persistence either.

The DAO layer creates TOs and initializes them with the hibernate POJO values. It also initializes dependant objects... so the TOs graphs looks almost the same as the Hibernate POJO model.

I hope this helps

Regards,
Matías

Ok, as far as I know, DTO is the most common pattern to solve this problem. I thing this is a good idea to use hibernate pojos as DTOs and fill them according to needs in business logic or presentation to avoid duplicating code by creating new DTOs. Do you think that it's too messy to provide several similar functions in DAO which differ only in the degree of filled data?
For example functions


I'm now working on some project where lots of code is written, but there's no lazy fetching and thus some performace problems appear. I need to solve this situation with the less possible impact to existing code. (Don't know whether it helps, but transaction demarcation is made in DAO layer via the Spring framework.)

thx, libor