• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

do i pass the @Entity to the caller?

 
Greenhorn
Posts: 5
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • 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?
 
Greenhorn
Posts: 5
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • 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
    Number of slices to send:
    Optional 'thank-you' note:
  • 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.
 
Ranch Hand
Posts: 39
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • 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.
 
Sheriff
Posts: 7134
1360
IntelliJ IDE jQuery Eclipse IDE Postgres Database Tomcat Server Chrome Google App Engine
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Chris Lb, please check your private messages regarding an important administrative matter.
 
Don't get me started about those stupid light bulbs.
reply
    Bookmark Topic Watch Topic
  • New Topic