Best practices for entities with lazy fields in a multi-J2EE-applications system [closed]

Closed. This question is opinion-based. It is not currently accepting answers. 开发者_如何学C

---

Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.

Closed 4 years ago.

Improve this question

I'm developing a system made up of several J2EE applications deployed on an Oracle Weblogic server, using Toplink as a JPA provider.

In my system, I have one application in charge of persistence (it reads and writes all my entities to/from the DB). Other applications use this application to access the data in the DB.

I also have one entity which holds a LOB field. The LOB field isn't always used when using this entity. Thus, I altered the entity so it will fetch the LOB field lazily.

But now I have a problem: When one of my applications is reading this entity from the persistence application, the returned entity is a normal POJO, detached from any EntityManager, so I can't read the LOB field (it was never invoked, thus never fetched).

I thought that maybe I could add a method to the persistence application that will fetch the entity completely (or the same method with a boolean parameter), but this will make the persistence application's interface too specific (what if I'll have more LOB fields in that entity?).

What would you do? What is the best practice in this case?

---

Use DTOs (data transfer object) - objects that are not entities, but are used to transfer data between applications / application layers.

There you have the freedom to decide which field is used when. For example:

class Service {
   LoblessResult getSimpleData(..);
   LobbedResult getCompleteData(..);
} 

where LoblessResult and LobbedResult are two classes containing a different subset of the fields of your entity.

If the only difference is that @Lob field - then the client should make a second request to obtain the value of that field. You will have only one DTO, that has all-but-one fields.