Несколько вопросов по сущностям в Jtalks опен-сорс проекте

 
 
 
Сообщения:23
Здравствуйте, ковыряюсь понемногу в опенсорс проекте здесь и возникли вопросы по сущностям:
1) Первое, что бросилось в глаза, - почему сущности не аннотированы (
@Id
,
@Entity
, ...), получается, что они не соответствуют требованиям JPA? Плюс к тому в доменном слое в jtalks-common есть абстрактные класс
Entity
, от которого унаследованы остальные сущности? Почему его не аннотировали как
@MappedSuperclass
, так же у этого абстрактного класса есть поле с идентификатором, тогда какая стратегия используется для генерации первичного ключа?
2) В упомянутом же выше абстрактном классе
Entity
, и, как результат, во всех остальных сущностях есть два атрибута:
private long id;
и
private String uuid = java.util.UUID.randomUUID().toString();
, то есть, по сути, два идентификатора? Зачем два?
3) На главной странице JTalks есть два репозитория: jcommune и jtalks-common. В сущностях jtalk-common с натяжкой кое - что для меня понятно, а вот в jcommune во многих сущностях есть помимо геттеров и сеттеров еще всякие другие методы, например в сущности
Branch
:
public Topic getNextTopic(Topic topic) {
        int index = this.getTopicIndexInList(topic);
        if (index == topics.size() - 1) {
            return null;
        }
        else {
            return topics.get(index + 1);
        }
    }

Разве это не должно находится в Service - слое?
 
 
Сообщения:9591
1. В ORM'ах есть 4 способа конфигурации сущностей: Native XML, Native annotations, JPA XML, JPA Annotations. Аннотации @Entity есть в Native annotations (там она deprecated) и в JPA Annotations. Мы же используем Native XML (файлы *.hbm.xml).

2. В equals() и hashCode() не принято использовать мутируемые поля ибо могут быть баги связанные с hash based коллекциями. Т.к. у новой сущности ID еще нет, а у сохраненной сущности он есть, то поле ID является мутируемым.

Желательно использовать какое-то уникальное неизменяемое поле, однако таких натуральных полей часто у сущностей нет. За сим мы решили в equals() и hashCode() использовать суррогатное поле UUID.

На практике же баги из-за изменяемого ID редко можно отхватить (у меня лишь один раз на опыте было) ибо чаще всего первым делом сущность сохраняют, а потом уже продолжают с ней работать, помещать в коллекции. Поэтому в большинстве проектов этим риском пренебрегают и не заводят отдельное поле. Вместо этого используют ID напрямую.

3. Нет. И если бы мы писали проект заново подобной логики в сущностях было бы намного больше. Сервисная логика и доменная логика - это разные вещи. Сервисная логика - это начать транзакцию, залогировать, быть фасадом (вызывать настоящую логику). Доменная (предметная) логика - это наш функционал, то зачем мы пишем наше приложение. Помещать такую логику в сервисы - очень нежелательно (хотя приходится, например, если нужно обратиться к внешнему ресурсу), в частности потому что это сильно вредит тестированию.
Изменен:14 ноя 2017 19:46
 
 
Сообщения:23
Староверъ, а почему вы в проекте не использовали просто тогда UUID для первичного ключа вместо Id? Разве этого было бы недостаточно?
 
 
Сообщения:9591
С функциональной точки зрения было бы достаточно. Однако строковые ID будут медленней работать при поиске/join'ах в БД, поэтому мы решили остаться на цифровых. Правда, мы так и не померяли насколько бы производительность отличалась. Может все было бы не так уж и плохо.
 
Модераторы:Нет
Сейчас эту тему просматривают:Нет