Generator-jhipster: [Suggestion] Introduce generic method names for MapStruct Object Mappers

[jCube1980]

Motivation for or Use Case

The interfaces generated by jhipster that are annotated with org.mapstruct.Mapper
have methods of the form

<%= entityClass %>DTO <%= entityInstance %>To<%= entityClass %>DTO(<%= entityClass %> <%= entityInstance %>);

<%= entityClass %> <%= entityInstance %>DTOTo<%= entityClass %>(<%= entityClass %>DTO <%= entityInstance %>DTO);

examples

CustomerDTO customerToCustomerDTO(Customer customer);
Customer customerDTOToCustomer(CustomerDTO customerDTO);

The proposal/suggestion is to use a generic base interface so that method names can be standardized.

public interface EntityMapper <D, E> {
    E toEntity(D dto); //suggested method names. Feel free to change.
    D toDto(E entity);
    List <E> toEntity(List<D> dtoList);
    List <D> toDto(List<E> entityList);
}

@Mapper(componentModel = "spring", uses = {})
public interface CustomerMapper extends EntityMapper<CustomerDTO, Customer> {}

Advantages

1) Standardized method names always lead to a better developer experience.
2) First up, developers need to remember fewer methods!
3) Developers don't have to visually select the method when using content assist. (They can select using memory)
4) Simplifies jhipster core implementation.

[gmarziou]

Are you sure this is technically possible with MapStruct?

As far as I know MapStruct uses method names to generate code similarly to Spring JPA repository findByNameAndEmail().

Have you made a proof of concept?

[jCube1980]

Yes sir, it will work. The code sample pasted above is based on what I tried out. MapStruct and spring-data-JPA are markedly different in their implementation approaches. MapStruct generates code at compile time. Spring data JPA does not generate code and the proxy-ing (obviously) happens at run time.

A detailed explanation of how spring-data-jpa works behind the scene can be found here

MapStruct actually generates code during compilation phase and for object mapping, it need not look beyond the parameter(s) and return type of the interface methods. The name can be any valid Java method name.

If the concern is about how generated methods resolve other mapping methods internally, the logic is explained here. Here also, method names are not used.

[gzsombor]

Good idea, I always thought that the current method names are overly verbose.
Could you create a pull request? The travis checks are reasonably thorough, so they should catch any problem ;-)

[jCube1980]

Sure sir, I'll get it a try.. :)

[jCube1980]

After a few initial hiccups with the travis builds, I finally got it all working. I've submitted a pull request for your consideration. While testing my changes, I uncovered an existing issue with jhipster. The entity sub gen cannot successfully generate an entity with the name 'Subscription' in Angular 4 based generated apps. The error message points to a name clash with an existing variable. Let me know.. I can submit a separate issue with additional details.

[pascalgrimaud]

@jCube1980 : yes if you find an issue, plz open a new ticket. Or maybe you can fix it directly and explain what you do in the PR : https://github.com/jhipster/jhipster-core/blob/master/lib/core/jhipster/reserved_keywords.js