Java Developer
  • Композиция vs Наследование в Java

    Обычно — inject-ить mock-и перечисленных объектов, проверять вызовы методов.

    Поддержал: Вадим Шаповал
  • Как и для чего собеседовать работодателя

    Я прошу посмотреть — глазами на ноутбуке, не доступ к репозиторию — код проекта. Кто-то сильно напрягается NDA, как будто у меня в пуговице шпионская камера, кто-то показывает — и тогда становится яснее, насколько сопромат на собеседовании коррелирует с реальным положением дел.

    Поддержали: Oleg Beloy, Vladislav Turevsky
  • Как использовать Hibernate: основные проблемы и их решения

    Спасибо за комментарий.

    А теперь представьте что DB всё-таки есть, и её охраняют 3 опасных DBA.
    Как везти разработку в таких условиях?

    Прочитал вопрос как «Что делать, если схема БД уже создана?» Два варианта: возможно Hibernate не нужен вообще, см. MyBatis. Либо JPA и «дизассемблировать» таблицы, большое количество полей «сгруппировать» с помощью @Embeddable, использовать enum и т.д.

    ваше виденье inheritance

    Я не сторонник использования наследования, это специфичный приём и должен применять аккуратно, вот моя старая, несколько наивная статья dou.ua/...​n-vs-inheritance-in-java

    Если наследование всё таки нужно, и проектировать от Java, то Hibernate прекрасно его поддерживает и предоставляет три стратегии для этого.

    Если «дизассемблировать» таблицы, то @MappedSuperClass для повторяющихся полей (например, в каждой таблице есть аудит createdBy, createdAt, modifiedBy, modifiedAt) мне не кажется хорошей идеей. Я предолжил бы использовать композицию и @Embeddable.

  • Меньше, но лучше: как повысить качество кода

    В итоге получается что простой код легко менять и поддерживать в не зависимости от того есть тесты или нет.

    Странное утверждение. Как можно «легко менять и поддерживать» без тестов?!
    Пример выше — простой, но плохой код.

    инструменты мутационного тестирования

    Статья же про качественный код? Имхо, если мутационное тестирование нужно, вряд ли это хороший код.

  • Меньше, но лучше: как повысить качество кода

    Не всегда.
    Классический пример. Простой и понятный код, только нетестируемый и поэтому с багом.

    public void congrats() {
        Date today = new Date();
        if (today.getMonth() == 1 && today.getDay() == 1) {
            System.out.println("Happy New Year!");
         }
    }
    
  • Меньше, но лучше: как повысить качество кода

    Тут нюанс. Вызов метода может быть весьма простым. И это может быть ок для внешних consumer-ов, пока не придётся править его бизнес-логику.

  • Меньше, но лучше: как повысить качество кода

  • ORM Сначала классы, потом таблицы

    Прямо под вашим комментарием другое мнение. В теме поста диаграмма базы и ддл для неё. Что скажете? Какие классы предложите?

  • ORM Сначала классы, потом таблицы

    У в предметной области нет другого поведения кроме как круд

    Эээ... Вроде как само определение «предметная область» подразумевает, что там поведение есть, если мы не совсем про записную книжку говорим.

    P.S. ORM considered harmful

    Без задачи такое утверждать некорректно.

  • ORM Сначала классы, потом таблицы

    Как можно «подбирать» классы под базу?! Это же телега впереди лошади!

    Так делают, в совсем тяжелых случаях 1:1. Тяжело работать в таких проектах, когда все дао, сервисы и т.д. уже написаны.

  • Как использовать Hibernate: основные проблемы и их решения

    Так вот, итоги.

    А таки что ви имеете пготив сегвисов?

    Таки имею. Что мой, что ваш сервисы — процедуры.

    ООП как раз тут и нет почти

    ... и поэтому на них нет юнит-тестов, сразу интеграционные.

    Не хотите? Добро пожаловать в мою модель.

    Я наконец-то понял о чём мы спорим. Это ORM vs Native SQLИнтенсивный JPQL, где на стороне ORM в плюсах полная свобода в модели и отсутсвие sql, когда можно просто пройтись по ней (что я и демонстрирую с помощью Entity->RRO). Только в случае Native SQL (+MyBatis) преимущество легче продемонстировать на каком-то аналитическом запросе, где ORM «вытянет несколько мегабайт данных» (цитата из другого топика), то c JPQL это невозможно неочевидно.

    Мне кажется, пока вы ограничены JPQL, в N+1 выиграть сложно, максимум паритет, и то за счёт написания запросов руками.

    Вы ближе ко второму подходу, поэтому пишите JPQL, накладываете ограничения (нет би-дирекшнл связям, иерархия и т.д.), но от вытягивания графа с помощью Hibernate.initialize() не отказываетесь.

    Вам не кажется эта структура офигеть каким искусственным, громоздким, излишним, error-prone и вообще неудачным решением?
    Извините, не удержался :-)

    Не то чтобы я явной благодарности прошу, скорее просто какой-то реакции, но, кажется, для интенсивного jpql вам нужен QueryDSL.

  • ORM Сначала классы, потом таблицы

    Кстати, да. Как иммутабельность с коллекциями-то?

  • ORM Сначала классы, потом таблицы

    Со скалой, увы, не знаком. Поэтому на snapeless/slick только попробую посмотреть. Добавил DDL в пост, если покажете, как оно на скале, буду дополнительно благодарен.

  • ORM Сначала классы, потом таблицы

    Покажите, пожалуйста. Добавил DDL схемы в пост.

  • ORM Сначала классы, потом таблицы

    Давайте переформулируем. Да, у меня круд. Это проблема?

  • ORM Сначала классы, потом таблицы

    А если БД уже есть?

  • ORM Сначала классы, потом таблицы

    Почему? Необязательно ведь Хибернейту DDL в базу разрешать, но можно же взять сгенеренную схему в скрипт flyway.

  • ORM Сначала классы, потом таблицы

    У меня есть небольшой опыт работы с Hibernate (см. статью). Я понимаю, как по классам строятся таблицы — это делает фреймворк. Я спрашиваю, как угадать классы по таблицам.

  • ORM Сначала классы, потом таблицы

    Если написать

    @Entity
    @Table(name = "orders")
    public class OrderEntity {
       @Id
       private Long id;
       // ...
       private Long clientId;
    }
    

    ...нужно вызывать потом метод по получению Client-а по его ID.

  • Как использовать Hibernate: основные проблемы и их решения

    Итоги падведьом ©

    Да, мы вроде уже возле финиша.

    Люблю Optional, не люблю isPresent(), написал бы через orElse.
    С другой стороны, вижу if — пишу тест, а orElse в глаза бросается только JaCoCo.

    Map снимает этот вопрос?
    Никоим образом.

    Извините, поспешил

    class Client {
      ... // /previous code
       @LazyCollection(LazyCollectionOption.EXTRA)
       private Map<Client, Friendship> friends;
    }
    
    В попытке держать метаданные дружбы клиентов и сохранить свою модель вы создали структуру, в которой клиент А содержит мапу из клиентов и объектов, у которых тоже по 2 клиента, причем в каждой паре 1 из клиентов — тот же А? У вас 4-уровневая (ой-вей!) структура из клиентов.
    Вам не кажется эта структура офигеть каким искусственным, громоздким, излишним, error-prone и вообще неудачным решением

    Неа, Map кажется мне простым и понятным решением, не зависящим от JPA и сервисов.

    Но спасибо, что подняли эту тему, допишу абзац про *-to-many.

    С одной стороны, я понимаю, что любое ТЗ вы можете решить в рамках своего подхода и с помощью сервисов, дробления графа и jpql не проиграть в N+1.

    С другой стороны, может правы и те, кто к вашим strict rules дополнительно запрещает *-to-many вообще, потому что сегодня там три записи, а завтра три миллиона, а код уже задеплоен.

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

← Сtrl 123456...12 Ctrl →