Win a copy of Cross-Platform Desktop Applications: Using Node, Electron, and NW.js this week in the JavaScript forum!
  • Post Reply Bookmark Topic Watch Topic
  • New Topic

do i pass the @Entity to the caller?  RSS feed

 
Jennifer Debroone
Greenhorn
Posts: 5
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
At work the guys wrote a DAO layer. I do the presentation side so I hook into their services with jndi lookups. They have a service called UserFascade for example and on that is a getNewUsers() function. When I call that, I get a List with the actual @Entity User {} objects back.

Is this the way its done? the actual Entity object is passed from the business method to the caller on the web side? Seems silly cause now I have access to the getPassword method ;) (although its hashed)

please advise on best practice?
 
Chris Lb
Greenhorn
Posts: 5
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
For EJB 3 the entity objects are DTOs too, or should I say they are DTOs annotated as entity objects. The annotations mark the DTOs for special use in the context(s) where the @Entity is applicable.
So, yes, they are dual purpose. In the UI they are simply DTOs. Once they get inside of an EJB transaction, they are entity objects (i.e. entity beans, but not called that) that will map changes to the underlying persistence when attributes are changed for entity instances that are already managed. persist() and merge() can be used with the entity manager (i.e. in the biz tier) within your EJBs to make a DTO that is passed into a managed entity. (using "make" loosely here)
If you inspect a managed entity in the UI, you may notice that the lists for one-to-many relationships are handled differently than regular lists and the annotated DTOs carry additional properties for the @Entity annotation effect on the DTO.
Hope that answers your question
 
Jennifer Debroone
Greenhorn
Posts: 5
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Chris Lb wrote:For EJB 3 the entity objects are DTOs too, or should I say they are DTOs annotated as entity objects. The annotations mark the DTOs for special use in the context(s) where the @Entity is applicable.
So, yes, they are dual purpose. In the UI they are simply DTOs. Once they get inside of an EJB transaction, they are entity objects (i.e. entity beans, but not called that) that will map changes to the underlying persistence when attributes are changed for entity instances that are already managed. persist() and merge() can be used with the entity manager (i.e. in the biz tier) within your EJBs to make a DTO that is passed into a managed entity. (using "make" loosely here)
If you inspect a managed entity in the UI, you may notice that the lists for one-to-many relationships are handled differently than regular lists and the annotated DTOs carry additional properties for the @Entity annotation effect on the DTO.
Hope that answers your question


Thanks very much for that answer. So what they are doing is this: in their session bean for the method getAllUsers, the stateless bean returns a List<User> where User is annotated as @Entity.

I include the jar with the @Entity object on my side (presentation side), i invoke their remote session bean via jndi and call the getAllUsers method. Now I have a list of User marked with the @Entity object. I don't see any transformation of the entity object, it looks just like it did on their side.. the presentation side resides on a different machine than their facade.. on my side, I dont have any JPA libs loaded, (the interfaces exist but no jpa provider).. Im to use the @Entity objects as pojo's..

does that make sense? thanks again

J.
 
Jonh Smith
Ranch Hand
Posts: 39
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
yes, the returned entities are not "managed". they are to be dealt with as pojos.
This is ok as long as the security environment of the presentation machine is sufficient and you actually use a reasonable amount of the returned User info. Otherwise if it may become a performance and/or security issue, a DTO that hides the sensitive stuff (i.e. password) and sticks to the bare minimum User content should be the way to go instead.
 
Devaka Cooray
Marshal
Posts: 5511
687
Chrome Eclipse IDE Google App Engine IntelliJ IDE jQuery Postgres Database Tomcat Server
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Chris Lb, please check your private messages regarding an important administrative matter.
 
It is sorta covered in the JavaRanch Style Guide.
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!