• 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

Pass JPA entities across tiers?

 
Greenhorn
Posts: 27
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Since JPA entities are POJO, do you think pass JPA entities instead of DTO across the tiers is a good practice?

For example: In presentation tier, we create a JPA entity object and set data into it with its setter. And then we pass this object to Session Facade as input parameter. Finally, Session Facade persistent the object into DB by EntityManager.

Your thoughts?
 
Ranch Hand
Posts: 211
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi Yi,

Please see your private messages on an unrelated subject

Thanks
 
Rahul Mishra
Ranch Hand
Posts: 211
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Furthermore to answer your question,

Using DTO's is an anti pattern (anaemic domain model) necessiated by the use of EJB's to transfer data (avoiding remote calls).Building persistent entities which move across layers tends to lead towards a richer domain model with the domain objects encapsulating data and behavior.

In my opinion, I dont see a reason why the examiners would think differently...

Hoping that someone will refute/second my comment.

Cheers
 
author and cow tipper
Posts: 5009
1
Hibernate Spring Tomcat Server
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Rahul Mishra wrote:
Using DTO's is an anti pattern (anaemic domain model) .



I couldn't agree more! It's frustrating to go into shops using JPA and EJB3, and see designs that build all these needless DTOs. Use your POJOs! That's what they are there for!

-Cameron McKenzie
 
Yi Chen
Greenhorn
Posts: 27
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Cameron Wallace McKenzie wrote:

Rahul Mishra wrote:
Using DTO's is an anti pattern (anaemic domain model) .



I couldn't agree more! It's frustrating to go into shops using JPA and EJB3, and see designs that build all these needless DTOs. Use your POJOs! That's what they are there for!

-Cameron McKenzie



Hi Cameron,

Do you mean that we could use JPA entities to transfer data across tiers?

Thanks!
 
Cameron Wallace McKenzie
author and cow tipper
Posts: 5009
1
Hibernate Spring Tomcat Server
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
JPA entities are just POJOs, right?
 
Ranch Hand
Posts: 1936
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Yi Chen wrote:
Do you mean that we could use JPA entities to transfer data across tiers?


Why not? Do you know why do we need TO when using Entity Beans? It's because Entity Beans are remote objects. We use TO to reduce network calls.
There is no point to create TO for JPA entities. Create it for what?
 
Greenhorn
Posts: 7
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Well, may be I need to refresh my understanding on DTO's, but don't we create the TO's to reduce the network calls and provide some meaningful response to the remote clients? (I think of EJB's).
Passing JPA Entities across layers is a good solution to trivial problems. But then we don't design databases according to UI screen, do we?
Lets say I have a presentation layer calling EJB and the user interface screen(UI) needs some data from multiple tables, is anybody suggesting that I pass JPA entities from these multiple tables (which no doubt are POJO's outside persistent context) to the presentation layer? Besides client may not be interested in everything and we definitely do not want everything in the database table to be visible to the client.
And to add more complexity, the database table may change for some other requirement/reasons (other than the UI screen we just discussed, say a new DBA was hired and the database undergoes normalization - new DBA wanted to show that employer has made right choice hiring him ), forcing our JPA entities to change. Do we want our poor presentation tier to change too?

Please don't shoot me
I would appreciate to any other views.
 
Cameron Wallace McKenzie
author and cow tipper
Posts: 5009
1
Hibernate Spring Tomcat Server
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

the database table may change for some other requirement/reasons forcing our JPA entities to change.



Absolutely NOT!!!

JPA entities are mapped to a database, but they are not 'tied' to a database. If the database changes, you change the mappings, not the objects. The objects stay the same. That's the whole point!

Passing JPA Entities across layers is a good solution to trivial problems.



It is the proper, standard and accepted solution to trivial AND very complicated problems.

But then we don't design databases according to UI screen, do we?



We don't design cars based on railroad tracks. What's the point?

suggesting that I pass JPA entities from these multiple tables (which no doubt are POJO's outside persistent context) to the presentation layer?



"JPA entities from multiple tables." What does that mean, and why does it matter?

A JPA entity is just a POJO. Why would someone not pass a POJO between layers? In fact, thats the ONLY thing we can pass between layers!

Besides client may not be interested in everything and we definitely do not want everything in the database table to be visible to the client.



A JPA entity should not represent everything in your database. That would be a very large entity, too large for a clien to handle. A POJO like a User with ten properties is typical.

but don't we create the TO's to reduce the network calls



The real reason we did this was because Entity Beans were remote objects and could not be sent across a network under any conditions. That was just bad design. We don't do that anymore. Now we have JPA entities that CAN be sent across a network. So, why wouldn't we send the entities across the network?









 
Vj Borkar
Greenhorn
Posts: 7
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Thanks for insight.
I stand corrected. Yes, We *map* the POJO's to database so what changes is the mapping.
I still have a doubt. What happens if a database table is spitted into multiple tables? Shouldn't the original JPA entity mapping change? If it was table per concrete class strategy, wouldn't we be forced to create new classes for new tables and to change the original JPA mapping?

About JPA entities from multiple table -> In general, UI screen would be aggregate of contents from multiple tables. If I assume table per concrete class strategy, wouldn't I be sending those POJO's (which were JPA entities in persistence context) from multiple tables?
 
Hong Anderson
Ranch Hand
Posts: 1936
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Purpose of using TO is to reduce network calls. If you don't want to reduce network calls, you don't need TO.
 
Greenhorn
Posts: 9
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I always like to do that but there is a problem

Issue is in collection with lazy load when JPA entity has one or more dependent table as collection
The collection won't load in web server. So we have to make sure that are loaded in EJB server before sending or avoid lazy loading

And for read only attribute or memory only attributes we can use @Transient
With @Transient option in JPA we can have some properties in entity which won't map to database so we can define some memory only attributes.

 
Cameron Wallace McKenzie
author and cow tipper
Posts: 5009
1
Hibernate Spring Tomcat Server
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

The collection won't load in web server. So we have to make sure that are loaded in EJB server before sending or avoid lazy loading



Yup! That's a challenge. "Open Session In View" works great if the EJB and Web container are on the same server/JVM, but in a more distributed environment, you'll need a service layer that makes sure all the data is there. Of course, that's not a Hibernate issue specifically, just a common issue when doing modern day enterprise programming.

-Cameron McKenzie
 
Ranch Hand
Posts: 240
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I agree with VJ.

the database table may change for some other requirement/reasons forcing our JPA entities to change.


- Absolutely NOT!!!

JPA entities are mapped to a database, but they are not 'tied' to a database. If the database changes, you change the mappings, not the objects. The objects stay the same. That's the whole point!

- it is common and nature for a class to be mapped to a table, which is good for maintenance. "the whole point" seems not make much sense: A tangled mapping will be a nightmare. In addition, what if you add columns to database table for some reason, and it need to be mapped to the same class by certain means. Are you mapping it to some class else? I won't.

Passing JPA Entities across layers is a good solution to trivial problems.



-It is the proper, standard and accepted solution to trivial AND very complicated problems.

-"AND very complicated problems"? I doubt.

But then we don't design databases according to UI screen, do we?



- We don't design cars based on railroad tracks. What's the point?
- The point is a car don't use railroad tracks, but UI screens use data from database tables.

suggesting that I pass JPA entities from these multiple tables (which no doubt are POJO's outside persistent context) to the presentation layer?



-"JPA entities from multiple tables." What does that mean, and why does it matter?
- because there might be multiple network communication to get many entities if you don't use DTO.

- A JPA entity is just a POJO. Why would someone not pass a POJO between layers? In fact, thats the ONLY thing we can pass between layers!
- still the reason is for network communication granularity, decoupling and... as Core j2ee pattern said, which still makes sense.

Besides client may not be interested in everything and we definitely do not want everything in the database table to be visible to the client.



- A JPA entity should not represent everything in your database. That would be a very large entity, too large for a clien to handle. A POJO like a User with ten properties is typical.
- Do you mean there are some columns in database table which is not mapped to entity? Or maybe mapped to other entity. Anyway if column is not mapped to any entity, how do you CRUD it?

but don't we create the TO's to reduce the network calls



- The real reason we did this was because Entity Beans were remote objects and could not be sent across a network under any conditions. That was just bad design. We don't do that anymore. Now we have JPA entities that CAN be sent across a network. So, why wouldn't we send the entities across the network?
- True, but after review the Core j2ee design pattern, I found that it is not the only reason.
 
Bigwood Liu
Ranch Hand
Posts: 240
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Plus, Cameron, I have one of your books about portal, it does help
 
Greenhorn
Posts: 4
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Yi Chen wrote:Since JPA entities are POJO, do you think pass JPA entities instead of DTO across the tiers is a good practice?

For example: In presentation tier, we create a JPA entity object and set data into it with its setter. And then we pass this object to Session Facade as input parameter. Finally, Session Facade persistent the object into DB by EntityManager.

Your thoughts?

We have merge operation in JPA just for this purpose.
The data send in from other tiers can be merged with the current data and can be persisted to DB.
Also as already discussed in this forum, the purpose of TO can be met using an entity as we would be having most of the properties we require to transfer to other layers in the entities.
 
And then we all jump out and yell "surprise! we got you this tiny ad!"
a bit of art, as a gift, that will fit in a stocking
https://gardener-gift.com
reply
    Bookmark Topic Watch Topic
  • New Topic