Where would it be correct to place the conversion methods dto -> entity and vice versa?

Question

Java

I thought about several options.
1. Place directly in the dto in each.
2. Create a separate DTOUtils class and drop everything there (but then there will be a mix of methods for converting all classes)
3. Make a dtoutils package and create many classes there (for each dto its own, they will only store dto methods and that’s all)

3 option looks like the most prudent, but creating a separate class for one method is somehow not very good.

P,S, I heard about the mapstract, but the logic of turning into a DTO and vice versa is complicated. Need to work with DB.

Answer 1

Good afternoon!

Post directly to the dto in each.

Why don't you add conversion methods to the service layer where you write your business logic.
For example, you have an entity User & dto - UserCreationDto. In the UserService service layer, create 2 methods that convert the entity < -- > dto.
If you use the built-in features of Spring ( Converter<S, T>), then you need to create a class for each entity. Regarding the location of the packages, there are different practices. For example, put User, UserCreationDto, UserRepository, UserService, UserToDtoConverter, etc. into the user package.
If you do not customize the conversion process in any way, then you can write one base class using generics.
Here is a simple example for ModelMapper:

@Service
@RequiredArgsConstructor
public class MapperService {

  private final ModelMapper modelMapper;

  /**
   * Note: outClass object must have default constructor with no arguments
   *
   * @param <D> type of result object.
   * @param <T> type of source object to map from.
   * @param entity entity that needs to be mapped.
   * @param outClass class of result object.
   * @return new object of <code>outClass</code> type.
   */
  public <D, T> D map(final T entity, Class<D> outClass) {
    return modelMapper.map(entity, outClass);
  }

  /**
   * Note: outClass object must have default constructor with no arguments
   *
   * @param entityList list of entities that needs to be mapped
   * @param outCLass class of result list element
   * @param <D> type of objects in result list
   * @param <T> type of entity in <code>entityList</code>
   * @return list of mapped object with <code><D></code> type.
   */
  public <D, T> List<D> mapAll(final Collection<T> entityList, Class<D> outCLass) {
    return entityList.stream().map(entity -> map(entity, outCLass)).collect(Collectors.toList());
  }

  /**
   * Maps {@code source} to {@code destination}.
   *
   * @param source object to map from
   * @param destination object to map to
   */
  public <S, D> D map(final S source, D destination) {
    modelMapper.map(source, destination);
    return destination;
  }
}

Create a separate DTOUtils class and drop everything there (but then there will be a mix of methods for converting all classes)

Not the best idea. It's better not to do that. Remember the Single Responsibility Principle. (SOLID).

Make a dtoutils package and create many classes there (for each dto its own, they will only store dto methods and that's it)

It all depends on your project. Sometimes having one package can be justified, and sometimes not. It is important to correctly form the structure of the project.

Option 3 looks like the most prudent, but creating a separate class for one method is somehow not very good.

This is exactly the case when you use the interface Converter<S, T>
https://docs.spring.io/spring-framework/docs/curre...
If you don't want to create one class for each dto, you can look at the code above . Maybe it will be useful for you

Answer 2

you are not catching up with the campaign what is dto and entity. Smart Western dudes name an entity with all sorts of business methods. But because of the annotations in the spring, people like you think that this is just a database model. No. And this is just a data model without methods, and this object is only needed to transfer data to another place.

conversion methods

it's called mappers, and yes, in java, it's easier to use libs for this, and it's not just a maptract. And there is nothing difficult
under the mappers, you can make a package next to the turnip, the turnip should already return the models. No one except turnips should know about dto