Формирование объекта с отношениями (JDBC)

Question

Формирование объекта с отношениями (JDBC)

1

Существует 3 объекта (которые соответствуют таблицам):

public class Enterprise{
  private long id;
  private String name;
  private List<Department> departments;

  //getters()/setters()
  }

public class Department{
  private long id;
  private String name;
  private List<Employee> employees;

  //getters()/setters()
  }

public class Employee{
  private long id;
  private String name;
  private List<Department> departments;

  //getters()/setters()
  }

ENTERPRISE--- | OneToMany | --- УПРАВЛЕНИЕ --- | ManyToMany | ---EMPLOYEE

Может ли кто-нибудь написать метод на JDBC:

List<Enterprise> findAll();

Связь, заявления, запросы и т.д. Можно игнорировать. Основная трудность состоит в том, чтобы установить все ссылки на правильные объекты (например, чтобы избежать: enterprise.getDepartments(). Get (1).getEmployees(). Get (1).getDepartments() == NULL).

ПРИМЕР (начало метода):

 List<Enterprise> findAll(){
    ResultSet rs = executeQuery(SELECT_ALL_ENTERPRISES);
            List<Enterprise> ents = createEnterprises(rs);
                .........

GeT_RiGhT 09 авг. 2014, в 02:35

Источник

0

Не могли бы вы объяснить, почему вы хотите сделать это с JDBC, а не с JPA?
Lukas Eder 16 авг. 2015, в 16:57

Теги:

java

sql

jdbc

dao

2 ответа

0

Многие библиотеки ORM позволяют вам определять отношения от одного до многих, как вы описали. Сормула может это сделать. См. Один из многих примеров.

Что мне нравится в Sormula, так это то, что если вы назовете поле внешнего ключа на "стороне" так же, как поле "с одной стороны", то Sormula выведет связь, и никакие аннотации не нужны.

Jeff Miller 09 авг. 2014, в 14:47

Ещё вопросы

Не могли бы вы объяснить, почему вы хотите сделать это с JDBC, а не с JPA?

Edwin Buck · Accepted Answer · 2014-08-08T22-47-00.000Z

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

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

Представьте себе человека, который хочет найти все департаменты, для чего потребуется поиск всех сотрудников (поскольку они являются частью объекта Департамента). Что потребует, чтобы для каждого сотрудника был необходимо найти список отделов, что потребует, чтобы эти департаменты нуждались в списке сотрудников, что...

Возможно, теперь у вас есть идея.

Так много систем, которые структурированы как ваши, на самом деле не возвращают полных Employees при поиске отделов. Они возвращают "Идентификаторы сотрудников". Это позволяет искать все департаменты, но гарантирует, что ни один сотрудник не будет возвращен, предотвращая бесконечный цикл. Затем, если человек достаточно заинтересован, они могут использовать идентификаторы сотрудника для поиска отдельных сотрудников, что, конечно же, будет содержать идентификаторы отдела.

Короче говоря, я рекомендую вам не перестраивать ассоциацию на этом уровне. Я предлагаю вам построить отключенные графики объектной сетки, чтобы можно было легко перемещаться по отключенному графику позднее. Затем, если вы действительно должны их подключить, вы, по крайней мере, будете загружать все данные без рекурсии, прежде чем начинать вязание ссылок.