Hi all, Can we talk about ... 1. Do one really need a DTO if using EJB 3.0 or Hibernate 2. How does Transfer Objects differ from that of EJB 3.0 entity beans or hibernate POJOs ? Thanks ~pp

I don't think so no. EJB3 has something called a session facade that is responsible for CRUD operations (create, update, delete) on entity beans, in addition to transferring them. So using an entity bean from a client is as easy as: EmployeeFacade facade = new EmployeeFacade(); Employee e = facade.getEmployeeByPk(1); e.setName("blabla"); facade.edit(e); // persisted ... - bjorn

In EJB 3.0 you dont need DTO. Because Enytity beans which were BMP and CMP in pre EJB 3.0 used to copy the objects to DTO's as BMP or CMP couldnt be send accross the wire. But With EJB -3.0 Enity Beans are POJOs, which means they can be serialized if they have to be sent across the wire. There is no need for seperate DTO's in EJB 3.0. Because POJO based Entity will act as DTO once it is out of persistent context. I hope this helps..... Vishal http://vashistvishal.blogspot.com

I don't think that direct use of entity beans outside of "application" is correct: 1. What do you do in case of lazy inicializations? How would you handle LazyInicializationException? 2. What about huge network transfer in case if entity holds some collection and you just want to edit the descirption? 3. Direct use of entities in session facade methods would cause that entities became a part of interface. Entities (or domain objects) are part of internal business logic not an application interface. So I prefer to use DTOs, specially in larger applications where adding one field to entity means to test 38 application modules. BTW. sorry for late posting.