Подход для Mapstruct Mappers с перегрузкой метода и InheritedConfiguration - PullRequest
0 голосов
/ 02 мая 2019

Мы используем MapStruct с данными Spring для преобразования между сущностями JPA и классами DTO. Все преобразователи следуют одному и тому же шаблону с методами beanToDTO () и dtoToBean (). После учебного курса у нас все это работает. Теперь мы пытаемся использовать Spring инъекцию для замены реализации на сущности JPA, классах DTO и Mapper. У нас есть субъекты JPA и замена DTO. Итак, теперь мы пытаемся внедрить альтернативную реализацию Mapper в Spring.

Для нашей задачи мы можем создать подкласс интерфейса преобразователя, и у него не будет 2 методов beanToDTO () и 2 методов dtoToBean (), 1 для базовой сущности JPA и DTO и 1 для подклассовой сущности JPA и DTO. Это хорошо работает для простых примеров.

Для картографов, которые требуют некоторой настройки, мы используем аннотацию @Mapping и @InheritInverseConfiguration для базового картографа. Для преобразователя подкласса мы пытаемся сделать то же самое, но проблема в том, что InheritInverseConfiguration в преобразователе подкласса выдает ошибку «Существуют несколько соответствующих обратных методов: beanToDTO (), beanToDTO (). Укажите имя явно».

Оба метода имеют одно и то же имя, поэтому у нас нет способа определить реализацию, на которую мы хотим сослаться. Я понимаю, что проблема связана с нашим подходом к реализации, но он упрощает наш код до: - getBean () - getMapper (). beanToDTO () и мы сможем заменить сущность JPA, Mapper и DTO посредством Spring инъекции.

Существуют ли другие уловки MapStruct, которые помогут нам с этой проблемой?

Спасибо

1 Ответ

0 голосов
/ 11 мая 2019

Смотрели ли вы на @MapperConfig .. оформление нашего модульного теста. Я бы посоветовал поместить ваши базовые / прототипные методы в @MapperConfig аннотированный интерфейс общей конфигурации, на который вы можете ссылаться в @Mapper

См. этот модульный тест для получения дополнительной информации. Или ознакомьтесь с руководством пользователя .

...