DTO to entity in Quarkus

[Ivan St. Ivanov]

Hi everyone,

In our project we have a generic class that converts a DTO to its corresponding entity. Something like a projection.

It walks through all the fields of the DTO and reflectively reads their value. Afterwards again reflectively it sets them to the entity object.

I'd like to have the same generic mapping class in our Quarkus project as well. However, using reflection in a Quarkus project is not a good idea, right? 

So what is the right way to convert from DTOs to entities (and vice versa) in Quarkus?

Thanks,

Ivan

[Ivan St. Ivanov]

No, I haven't, thanks Harald! :)

On Thu, Dec 19, 2019, 22:10 Harald Pehl <hp...@redhat.com> wrote:

Have you tried MapStruct [1]?

// Harald

[1] https://mapstruct.org/news/2019-12-06-mapstruct-and-quarkus/

--
You received this message because you are subscribed to the Google Groups "Quarkus Development mailing list" group.
To unsubscribe from this group and stop receiving emails from it, send an email to quarkus-dev...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/quarkus-dev/CACYLA9E0YY9Q6TP9TbjMO8PiKpzhXAiC7Uw4fK%2B3-%3D3AbCT1jA%40mail.gmail.com.

[Rafael Kloss]

Ivan,

We are using https://mapstruct.org/, take a look on "general philosophy"

The general philosophy of MapStruct is to generate code which looks as much as possible as if you had written it yourself from hand. In particular this means that the values are copied from source to target by plain getter/setter invocations instead of reflection or similar

In my opinion, is the best option !

Regards

To view this discussion on the web visit https://groups.google.com/d/msgid/quarkus-dev/CACYLA9FjHcku7LXVqweHTFYk0AeU%2BX3Ee2h8c3c2hAaNsFUwXw%40mail.gmail.com.

--

{ name     : "Rafael Kloss",

  location : "Curitiba, PR",

  iata     : "CWB",

  twitter  : ["@rafa_kloss"}

[Ivan St. Ivanov]

Thank you, too, Rafael! :)

[Manyanda Chitimbo]

Here is the rich blog post 

https://mapstruct.org/news/2019-12-06-mapstruct-and-quarkus/ from the MapStruct team to help you along the way. 

To view this discussion on the web visit https://groups.google.com/d/msgid/quarkus-dev/CACYLA9GpMMt7V85ah8ammX1Es3iCWyBb4OpZ8O5cpdWPvjd_2g%40mail.gmail.com.

--

Manyanda Chitimbo.

[Emmanuel Bernard]

Reading that blog

Very important: The component model should be set to CDI, as this will allow us to easily inject the generated mapper implementation.

Side note: As you need to use CDI for all mappers it’s recommended to define a @MapperConfig and refer to it in all your mappers, this is the way I did it in the example on GitHub. But for simplicity I skipped it here.

Time for an extension that actually enforces that! This is madness otherwise (well I might exaggerate the madness part :).

To view this discussion on the web visit https://groups.google.com/d/msgid/quarkus-dev/CANwCmXKGzJs6n%3DDj_vSD3q%2BW0P6qCh_p0jrW7jzn6nX8%3D2Lwhg%40mail.gmail.com.

[Manyanda Chitimbo]

Yes, having a MapStruct extension in the long run will help with all this manual setup “madness” ;-) 

IIRC, Gunnar and Guillaume discussed about it at some point, but cannot recall the outcome. So depending on that and priorities, this could be something I could look at once I am back from vacations. 

--

Manyanda Chitimbo.

[Loïc MATHIEU]

Hello Ivan,

In my opinion (maybe not everybody will agree) reflection is fine inside your code.

We try to avoid it inside Quarkus to be easily compatible with GraalVM native image, and because we use Jandex to gather class metadata at build time that is more convenient than reflection for what Quarkus needs. 

It also allows Quarkus to start quicker.

But inside your application code, reflection can be a good solution as it's very convenient.

If you don't plan to deploy your application as a native image, no problem with reflection.

If you plan to deploy it as a native image, you need to configure SubstratVM (the VM that is embedded via the native image tool) to enlist your class for reflection as SubstratVM needs to know which class is eligible for reflection to avoid removing the class at  image build time (what is called DCE - Dead Code Elimination).

Fortunately for you, Quarkus has you covered by providing the @RegisterForReflection annotation: https://quarkus.io/guides/writing-native-applications-tips#registering-for-reflection

This annotation is not always needed as Quarkus will automatically register some types for reflection but if you want to be sure, you can use it.

Regards,

Loïc

To view this discussion on the web visit https://groups.google.com/d/msgid/quarkus-dev/CANwCmX%2B9h9WXavXBkEQuYGxQ5L9a82khqWFo5SGb8CG9DhnMYA%40mail.gmail.com.

[Ivan St. Ivanov]

Thanks Loic for your explanation!

Now we are looking into which approach is better from dev experience point of view: using the mapstruct library (and presumably soon the Quarkus extension) or going down the @RegisterForReflection path.

Cheers,

Ivan