Многие ко многим связаны с инверсией зависимостей - PullRequest
0 голосов
/ 24 мая 2019

У меня есть многомодульное приложение с двумя модулями:

  • отдел-менеджмент
  • коммуникационно-менеджмент

теперь в моем department-management у меня есть сущность Department, а в модуле communication-management у меня есть MailingGroup сущность.

Также управление коммуникациями зависит от модуля управления отделами. Теперь я хочу иметь двунаправленное ManyToOne отношение между Department и MailingGroup

@Entity
public class Department {

   @OneToMany(mappedBy = "department")
   List<MailingGroup> mailingGroups;
}


@Entity
public class MailingGroup{

   @ManyToOne
   @JoinColumn(name = "DEPARTMENT_ID")
   Department department;
}

Это, конечно, не архивируется вышеописанным способом, но могу ли я заархивировать это двунаправленное отношение, используя интерфейсы? Моей первоначальной идеей было решить это так:

public interface MailingGroupProvider {
    Department getDepartment()
}

@Entity
public class Department {

   @OneToMany(mappedBy = "department")
   List<MailingGroupProvider> mailingGroups;
}


@Entity
public class MailingGroup implements MailingGroupProvider {

   @ManyToOne
   @JoinColumn(name = "DEPARTMENT_ID")
   Department department;
}

Но это вызывает вопросы:

  • Является ли это предпочтительным решением в таких случаях?
  • Какие методы должен предоставить мой интерфейс для обработки JPA как Entity?
  • это вообще возможно, что я пытаюсь сделать?

1 Ответ

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

Первый подход идеален: вам нужно добавить отношение в обе стороны сущности.

detamentid - это внешний ключ почтовой группы Table.Примените Отношения в обеих сторонах юридического лица, это будет работать.

@ OneToMany Relationship означает, что у вас может быть один Департамент, может иметь много Коммуникаций.

Двунаправленные средства предполагают, что если вы выполняете какие-либо операции в Управлении коммуникациями, такие как удаление сообщений, это также повлияет на таблицу Отделов.Будет удален Departmentid, соответствующий в таблице отдела

...