Implement Automatic DTO Mapping Feature...

[Mouon]

Implement Automatic DTO Mapping Feature

I am leaving an issue to learn from great people 🙏🏻 🙏🏻 🙏🏻

Issue

Implement Automatic DTO Mapping Feature
Description:
We need a feature to automatically convert entity lists obtained from @query into DTOs. The goal is to add logic that uses reflection to automatically map values from entity fields to DTO fields with the same names.
Objectives:

Implement a method for automatic mapping from entities to DTOs
Use reflection for field mapping Handle exceptions for mapping failures

Sample Code:

import ...

public class AutoMapper {
    @Nullable
    public static <D, E> D mapEntityToDto(Class<D> dtoClass, @Nullable E entity,
                                          MappingContext<? extends PersistentEntity<?, ?>, ? extends PersistentProperty<?>> mappingContext) throws Exception {
        Assert.notNull(dtoClass, "DTO class must not be null");
        Assert.notNull(mappingContext, "MappingContext must not be null");
        
        if (entity == null) {
            return null;
        }
        
        Constructor<D> constructor = dtoClass.getConstructor();
        D dtoInstance = constructor.newInstance();
        
        PersistentEntity<?, ?> persistentEntity = mappingContext.getPersistentEntity(entity.getClass());
        if (persistentEntity instanceof JpaPersistentEntity) {
            JpaPersistentEntity<?> jpaPersistentEntity = (JpaPersistentEntity<?>) persistentEntity;
            for (JpaPersistentProperty property : jpaPersistentEntity) {
                String propertyName = property.getName();
                Field dtoField = ReflectionUtils.findField(dtoClass, propertyName);
                if (dtoField != null) {
                    ReflectionUtils.makeAccessible(dtoField);
                    Object value = property.getGetter().invoke(entity);
                    ReflectionUtils.setField(dtoField, dtoInstance, value);
                }
            }
        }
        
        return dtoInstance;
    }
}

Benefits

Simplifies mapping process

Can be used with @query annotations, e.g.

@Query("SELECT new com.server.dto.gitHubIssue.GithubIssueListResponse$GithubIssue")

Note for Reviewers

I'm new to this and would greatly appreciate any guidance or suggestions for improvement. Thank you for your time and expertise! 🙏🏻

[mp911de]

For the time being, you can already use constructor expressions in your query. Meanwhile, we have a similar ticket in the issue tracker with #3076 to rewrite String-based queries into Constructor expressions so that the underlying JPA provider instantiates your class through a constructor.

That way, the constructed type maintains its integrity. In contrast, creating an empty object instance and populating its fields violates the principle of an integer object. At what state does the object become valid/usable and how do you even verify that state?

This specific concern addresses a class of potential bugs that we can eliminate by not introducing partially populated objects.

[Mouon]

For the time being, you can already use constructor expressions in your query. Meanwhile, we have a similar ticket in the issue tracker with #3076 to rewrite String-based queries into Constructor expressions so that the underlying JPA provider instantiates your class through a constructor.

That way, the constructed type maintains its integrity. In contrast, creating an empty object instance and populating its fields violates the principle of an integer object. At what state does the object become valid/usable and how do you even verify that state?

This specific concern addresses a class of potential bugs that we can eliminate by not introducing partially populated objects.

Hello, mp911de,

Thank you for your comment! I agree that constructor expressions can currently be used. However, if an automatic DTO mapping feature is provided, we can add logic to verify that field names and types match, which would help prevent mapping failures.

A key point here is that the default behavior should be to create objects through the constructor and fill all fields. This will help maintain the integrity of the object.

Additionally, since there are already issues with partially populated objects being created in JPQL, I believe that an automatic DTO mapping feature could address this problem. If automatic mapping is implemented, users will be able to safely create objects using constructors that contain all fields of the DTO.

In this regard, could the automatic DTO mapping feature contribute to solving existing problems? I would also like to express that my main goal is to learn from your valuable experience and knowledge, mp911de.

(Instead of simply suggesting an opinion, my intention is more to gain insights from your expertise.)

[mp911de]

an automatic DTO mapping feature is provided, we can add logic to verify that field names and types match, which would help prevent mapping failures.

I think that is doable in the course of #3076

A key point here is that the default behavior should be to create objects through the constructor and fill all fields. This will help maintain the integrity of the object.

That's the goal of the mentioned ticket.

Thanks for your response. Looking at your request and the thoughts behind it, I would close this ticket as duplicate of #3076.