Сохранение Hibernate Lazy loading в шаблоне проектирования объектов передачи данных

Question

Обычно я работаю над трехуровневыми приложениями, использующими Hibernate в уровне персистентности, и я стараюсь не использовать классы модели домена в уровне презентации. Вот почему я использую шаблон дизайна DTO (Data Transfer Object).

Но у меня всегда есть дилемма в моем объектно-ориентированном сопоставлении. Я теряю ленивую загрузку, или создаю сложность кода, вводя фильтры для вызова или не модели домена getters.

---

Пример:Рассмотрим DTO UserDto, что соответствует сущности пользователя

public UserDto toDto(User entity, OptionList... optionList) { 

     if (entity == null) { 
      return null; 
     } 

     UserDto userDto = new UserDto(); 
     userDto.setId(entity.getId()); 
     userDto.setFirstname(entity.getFirstname()); 


     if (optionList.length == 0 || optionList[0].contains(User.class, UserOptionList.AUTHORIZATION)) { 
      IGenericEntityDtoConverter<Authorization, AuthorizationDto> authorizationConverter = converterRegistry.getConverter(Authorization.class); 

      List<AuthorizationDto> authorizations = new ArrayList<>(authorizationConverter.toListDto(entity.getAuthorizations(), optionList)); 
      userDto.setAuthorizations(authorizations); 

... 
} 

OptionList используется для фильтрации отображения и отображения только что хотел.

Хотя последнее решение допускает ленивую загрузку, но оно очень тяжелое, поскольку в сервисном слое должен быть указан optionList.

---

Есть ли лучшее решение для сохранения отложенной загрузки в шаблоне проектирования DTO?

Answer 1

Для одного и того же постоянного состояния я не люблю иметь поля объекта, не инициализированные в некотором пути выполнения, в то время как эти поля также могут быть инициализированы в других случаях. Эта причина слишком много головной боли для поддержания:

• это вызовет NullPointer в лучших случаях
• если null также является допустимым вариантом (и, следовательно, не вызывают NullPointer), это может означать, что данные были удалены, и может вызвать неожиданные бизнес-правила удаления, в то время как данные на самом деле все еще существуют.

Я предпочел бы создать иерархию DTO интерфейсов и/или классов, начиная с UserDto. Все фактические поля реализации dto заполняются, чтобы отразить постоянное состояние: если есть данные, поле dto не равно null.

Так то вам просто необходимо обратиться к сервис-слой, реализация DTO вы хотите:

public <T extends UserDto> T toDto(User entity, Class<T> dtoClass) { 
    ... 
} 

Затем в слое службы, вы можете иметь:

Map<Class<? extends UserDto>, UserDtoBUilder> userDtoBuilders = ... 

где вы регистрируетесь различные разработчики, которые будут создавать и инициализировать различные реализации UserDto.

Answer 2

Я не уверен, зачем вам нужна ленивая загрузка, но я думаю, потому что ваш UserDto обслуживает несколько изображений через конфигурацию optionList? Я не знаю, как выглядит ваш код уровня презентации, но, наверное, у вас есть код if-else для каждого элемента в optionList?

Как насчет того, чтобы иметь разные представления, т. Е. Подклассы? Я спрашиваю об этом, потому что я хотел бы предложить попробовать Blaze-Persistence Entity Views. Вот небольшой пример кода, который подходит вашему домену.

@EntityView(User.class) 
public interface SimpleUserView { 
    // The id of the user entity 
    @IdMapping("id") int getId(); 

    String getFirstname(); 
} 

@EntityView(Authorization.class) 
public interface AuthorizationView { 

    // The id of the authorization entity 
    @IdMapping("id") int getId(); 

    // Whatever properties you want 
} 

@EntityView(User.class) 
public interface AuthorizationUserView extends SimpleUserView { 

    List<AuthorizationView> getAuthorizations(); 
} 

Это DTOS с некоторыми метаданными о отображении на модель объекта. И тут приходит использование:

@Transactional 
public <T> T findByName(String name, EntityViewSetting<T, CriteriaBuilder<T>> setting) { 
    // Omitted DAO part for brevity 

    EntityManager entityManager = // jpa entity manager 
    CriteriaBuilderFactory cbf = // query builder factory from Blaze-Persistence 
    EntityViewManager evm = // manager that can apply entity views to query builders 

    CriteriaBuilder<User> builder = cbf.create(entityManager, User.class) 
     .where("name").eq(name); 
    List<T> result = evm.applySetting(builder, setting) 
     .getResultList(); 
    return result; 
} 

Теперь, если вы используете его как service.findByName("someName", EntityViewSetting.create(SimpleUserView.class)) он будет генерировать запрос как

SELECT u.id, u.firstname 
FROM User u 
WHERE u.name = :param_1 

и если вы используете другой вид, как service.findByName("someName", EntityViewSetting.create(AuthorizationUserView.class)) он будет генерировать

SELECT u.id, u.firstname, a.id 
FROM User u LEFT JOIN u.authorizations a 
WHERE u.name = :param_1 

Помимо возможности избавиться от сопоставления объектов вручную, производительность улучшится из-за использования оптимизированных запросов!