aspose file tools*
The moose likes Architect Certification (SCEA/OCMJEA) and the fly likes Pass JPA entities across tiers? Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of Soft Skills this week in the Jobs Discussion forum!
JavaRanch » Java Forums » Certification » Architect Certification (SCEA/OCMJEA)
Bookmark "Pass JPA entities across tiers?" Watch "Pass JPA entities across tiers?" New topic
Author

Pass JPA entities across tiers?

Yi Chen
Greenhorn

Joined: Apr 28, 2006
Posts: 27
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?


SCJP 1.4 - 63%
SCEA part I - 100% part II - ing
Rahul Mishra
Ranch Hand

Joined: Jan 22, 2006
Posts: 211
Hi Yi,

Please see your private messages on an unrelated subject

Thanks


OCMJEA/SCEA, SCDJWS, SCBCD 1.3, SCJP 1.4
My SCEA experience:http://javalogue.blogspot.com/
Rahul Mishra
Ranch Hand

Joined: Jan 22, 2006
Posts: 211
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
Cameron Wallace McKenzie
author and cow tipper
Saloon Keeper

Joined: Aug 26, 2006
Posts: 4968
    
    1

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

Joined: Apr 28, 2006
Posts: 27
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
Saloon Keeper

Joined: Aug 26, 2006
Posts: 4968
    
    1

JPA entities are just POJOs, right?
Hong Anderson
Ranch Hand

Joined: Jul 05, 2005
Posts: 1936
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?


SCJA 1.0, SCJP 1.4, SCWCD 1.4, SCBCD 1.3, SCJP 5.0, SCEA 5, SCBCD 5; OCUP - Fundamental, Intermediate and Advanced; IBM Certified Solution Designer - OOAD, vUML 2; SpringSource Certified Spring Professional
Vj Borkar
Greenhorn

Joined: Jan 10, 2007
Posts: 7
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.


Regards,
VJ
SCJP 1.4, SCJP 6.0, SCWCD 1.4
Cameron Wallace McKenzie
author and cow tipper
Saloon Keeper

Joined: Aug 26, 2006
Posts: 4968
    
    1

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

Joined: Jan 10, 2007
Posts: 7
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

Joined: Jul 05, 2005
Posts: 1936
Purpose of using TO is to reduce network calls. If you don't want to reduce network calls, you don't need TO.
Ali Kianzadeh
Greenhorn

Joined: Aug 31, 2009
Posts: 9
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
Saloon Keeper

Joined: Aug 26, 2006
Posts: 4968
    
    1

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
Bigwood Liu
Ranch Hand

Joined: Feb 26, 2003
Posts: 240
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

Joined: Feb 26, 2003
Posts: 240
Plus, Cameron, I have one of your books about portal, it does help
prasune john
Greenhorn

Joined: Oct 29, 2010
Posts: 4
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.
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: Pass JPA entities across tiers?