Entities <-> Records Assembler

[m-reza-rahman]

I think the use cases outlined here are good. Does it also make sense to add something for the cases where DTO Record <-> Entity assembly happens outside the direct EntityManager context? Basically I am thinking of a generic utility that formalizes the Assembler Pattern in JPA. The utility could be a part of JPA itself or something that is part of DeltaSpike. The following are some casual examples representing very simple implicit transformation cases.

MyRecord myRecord = JpaDtoAssembler.toRecord(myEntity, MyRecord.class);
...
MyEntity myEntity = JpaDtoAssembler.toEntity(myRecord, MyEntity.class);

Reza Rahman
Jakarta EE Ambassador, Author, Blogger, Speaker

Please note views expressed here are my own as an individual community member and do not reflect the views of my employer.

[beikov]

I worked on something more general called Entity Views(imagine it like Spring Data Projections on steroids) that allow you to apply projections onto an existing query. This allows you to decouple business logic from projection logic and also improves performance because the actual query is transformed to fit the need of the projection.

IMO JPA should go into this direction as well, or maybe this needs a new specification? Here is an example that shows what Entity Views is about: https://github.com/Blazebit/blaze-persistence#entity-view-usage

Here you can find information about the integration with DeltaSpike: https://persistence.blazebit.com/documentation/entity-view/manual/en_US/index.html#deltaspike-data-features

[kalgon]

@m-reza-rahman, isn't that kind of feature better kept in a separate library like mapstruct?

[m-reza-rahman]

isn't that kind of feature better kept in a separate library...?

I think it really depends on how commonly used we think this will be. To me at least this appears to be the predominant use case. If that hypothesis is correct, this is actually best maintained as part of JPA itself I think.

Reza Rahman
Jakarta EE Ambassador, Author, Blogger, Speaker

Please note views expressed here are my own as an individual community member and do not reflect the views of my employer.

[kalgon]

It depends if entities and records are isomorphic or not.

If they are isomorphic, then I think it would not be too hard to have some kind of automatic mapping between the two. It could be based on the convention that names & types of entities attributes must match names & types of records components. This option is easy but I fail to see its benefits as you need to create and maintain 2 identical classes structures.

If they are not isomorphic, then it becomes a lot more complicated and a lot of questions need to be answered first:

• How do you map between entities and records?

  • Declaratively with annotations? But then, how do you express complex transformations/projections?
  • Programmaticaly? Do we need a framework for that or is simple java code enough?

• As you can lose information in the mapping/transformation (like summing/concatenating values), it is not always possible to convert a record back to an entity, is that a problem?

[m-reza-rahman]

These are certainly good questions. The following is what I had in mind:

• I am actually a DDD practitioner. For me an entity is a fairly complex model of an important part of the domain. That means Entities for me have both state and behavior. They also tend to be fairly comprehensive in encapsulating the part of the domain that is modeled.
• A DTO for me really is what a record is - simply a data holder with a minimal set of fields geared towards a simple communication use case outside the current bounded context. That means they tend to just copy a subset of the data parts of an entity (not the entire entity with all it's complexities and not the business logic).
• I think a utility should be as simple as copying "fields", doing some simple type conversion and some renaming. I think all that could be done with implicit defaulting and maybe some very simple field level annotations. I think for anything more complicated than that, a hand-written Assembler would be easier anyway.

Sorry for the DDD references. I wish there was a simpler yet equally complete way to communicate the ideas. I am happy to explain further if needed.

Reza Rahman
Jakarta EE Ambassador, Author, Blogger, Speaker

Please note views expressed here are my own as an individual community member and do not reflect the views of my employer.

[kalgon]

Don't worry, I am also a proponent of DDD (and a happy owner of the red and blue books). I even made some suggestions to make JPA DDD-friendlier some years ago (without much success).

I also see Value-Objects being implemented as records, that's why I would like to use them as attributes in Entities.

I think we both agree that complex mapping should be hand-written while simple mapping could be implicit. I am less sure about type conversion because that would make one more conversion mechanism to have... in that regard, I really think the Java EE platform should provide a common/generic conversion framework that could integrate with all other specs instead of having to implement the same logic in JPA AttributeConverters, JSF Converters and JAX-RS ParamConverter(Provider)s, JAX-B XMLAdapters, JSON-B JsonbAdapters, etc.

[m-reza-rahman]

FYI I am taking a closer look at MapStruct now and it seems in general just about right (although I need to check if they really support Records). It depends on code generation instead of reflection but I can overlook that. I am thinking that it is a good idea to add that to the analysis even if nothing is done in JPA itself. What do you think?

Reza Rahman
Jakarta EE Ambassador, Author, Blogger, Speaker

Please note views expressed here are my own as an individual community member and do not reflect the views of my employer.

[otaviojava]

@m-reza-rahman IMHO, we should work to make JPA compatible with Records such as any that handle Data on Jakarta/MicroProfile.

I wrote an article about it:

https://dzone.com/articles/jpa-constructor