소개
게시글
질문&답변
2021.10.05
연관관계 매핑 어떤식으로 해야될지 감이 안잡힙니다.
회원(User) 엔티티가 있고 회원은 소방회원(UserFire) , 병원회원(UserDoctor)으로 나뉩니다 그래서 회원 테이블엔 회원과 관련된 공통된 정보를 소방회원 테이블은 소방 관련 회원 정보를 병원회원 테이블엔 병원 관련 회원 정보를 넣고 싶습니다. 여기까진 상속 연관관계로 하면 된다는걸 알고 있고 소방회원이 필요한 기능에선 소방회원을 불러오고 병원회원이 필요한 기능에선 병원회원을 불러오면 되겠지만 상속구조로 할경우 다음과 같은것은 어떻게 해야될까에 대해서 모르겠습니다. 1. 로그인 로그인할때는 이 사람이 소방인지 병원인지 모르므로 User로 받아 온뒤 if(user instanceof Fire) { } 와 같은 과정으로 누구인지까지 알아낸다고 해도 매번 로그인된 사용자를 확인해야되는 로직에서 instanceof 하는 과정으로 형변환이 User -> UserFire or UserDoctor로 이루어지는 로직이 있어야되는건가? 라는 고민이 있습니다. 그냥 User에 이사람이 소방인지 병원인지 하는 정보가 변수로 들어가있어서 확인은 어렵지 않다 한들 결국 그 상세 정보(소방, 병원)에 접근하기 위해서는 형변환이 이뤄져야 하는것 맞나요? 2. 사용자 리스트 불러올때 소방 사용자 목록 이라는 기능이 있거나 병원 사용자 목록 이라는 기능이 있으면 애초에 리스트를 조회할때 각각 받으면 되는 문제지만 List 전체사용자 = userRepository.findAll() 해야되는 경우도 존재합니다. 이때도 받아온 사용자를 for(User user : 전체사용자){ if(user instanceof UserFire){ } if(user instanceof UserDoctor){ } } 이런 로직을 돌면서 형 변환을 해줘야 하나요. 소방사용자 목록 , 병원사용자 목록 분기해서 리턴하는게 아니라 전체사용자(각각 형변환 되어있는)로 리턴 하고 싶은데 이럴땐 어떻게 하는지를 모르겠습니다 그냥 List로 리턴하면 User 엔티티에 있는 정보들까지는 접근이 가능하지만 나머지 정보들은 접근이 안되니까요 이것도 설명이 횡설수설 같은데 users : {[ 0: { 사용자정보..., 소방정보 }, 1: { 사용자정보..., 소방정보 }, 2: { 사용자정보..., 의사정보 }, 3: { 사용자정보..., 소방정보 }, 4: { 사용자정보..., 의사정보 }, ]} 이런 형태로 리턴할수 있는가 입니다.
- 0
- 4
- 421
질문&답변
2021.09.30
연관관계 매핑 어떤식으로 해야될지 감이 안잡힙니다.
질문이 정리가 안되고 횡설수설 한것같아 다시 정리해서 질문드립니다 ㅜㅜ @Entity @Inheritance(strategy = InheritanceType.JOINED) @DiscriminatorColumn(name = "DTYPE") public abstract class Item { @Id @GeneratedValue @Column(name = "item_id") private Long id; private String name; private int price; } @Entity @DiscriminatorValue("B") public class Book extends Item { private String author; private String isbn; } @Entity @DiscriminatorValue("A") public class Album extends Item { private String artist; } @Entity @DiscriminatorValue("M") public class Movie extends Item { private String director; private String actor; } 상속 연관관계에서 가장 많은 예시로 사용되는 Item 과 Movie, Album, Book 예시로 질문드립니다 위의 예시에서 각각 Book, Movie, Album의 Repository가 만들어지고 @Repositorypublic interface ItemRepositoryT extends Item> extends JpaRepositoryT, String> {} ItemRepository는 위와 같이 구현 되었다고 볼때 이런식으로 사용될수도 있지만 List bookList = bookRepository.findAll(); List movieList = movieRepository.findAll(); List bookList = albumRepository.findAll(); 아래와 같이 Item으로 받을수도 있는데, 그때 아래와 같이 getClass하거나 instansof를 통해 어떤 자식클래스인지 확인 가능하고 형변환도 가능한것을 확인했습니다. List itemList = itemRepository.findAll(); for(Item item : itemList){ System.out.println(item.getClass().toString()); // Book, Album, Movie 클래스임을 확인. } 질문: 로직상 Book, Album, Movie를 직접 조회할일은 거의 없고Item 만으로 조회해야되는 일이 빈번할 경우는 어떤식으로 로직을 짜야할지모르겠습니다. 시스템입장에선 조회 전에 내가 조회할게 Book인지 Movie인지 모르는 상황이라 Item으로 조회해야만 하는 상황이고 조회 후에 아래 코드 처럼 instanceof를 통해 형변환 해주면 된다 치지만 // 단일 조회일 경우 Item item = itemRepository.findById(id); Book book; if(item instanceof Book){ book = (Book) item; } 단일 조회가 아닌 전체 리스트 조회일경우는 어떤식으로 해야하는지 감이 안잡힙니다 ㅜㅜ // 리스트 조회할경우 ? List itemList = itemRepository.findAll(); for(Item item : itemList){ ??? } 리스트로 조회할때 ORDER BY나 페이징 까지 고려되서 소트된 데이터가 올거라 포문 돌면서 형변환 하고 각각의 리스트에 다시 담기도 어렵고 JPA를 이용해 애초에 받아올때 각각 맞는 클래스에 맞게 받아와서 하나의 리스트에 담는 방법이 없나요?bookList, movieList가 아닌 ItemList 하나만 존재해야 할경우 어떤식으로 해야하나요? List itemList ; ================= 위의 예를 제 상황에 맞게 변경하자면 Item = 사용자 (계정정보) Book = 소방사용자 (소방관련 정보 포함) Movie = 의사사용자 (의사관련 정보 포함) Album = 기타 사용자 (그외 필요 정보 포함) 로 둘수가 있겠죠. 그런데 시스템 로직상 소방사용자만 조회한다던가 의사사용자만 조회한다던가 하는 기능도 있을수 있지만 전체사용자를 계정정보 관련 소트로 불러온뒤 ( Item 리스트를 Item에 해당하는 소트로 불러온뒤) 소방사용자1, 소방사용자2, 의사사용자1, 소방사용자3, 의사사용자2 . ... 이런식으로 불러와야 되기때문에 List 로 불러와야 되기도하고 로그인, 계정정보수정과 같은 공통된 '사용자' 관련 기능들 구현시에도 추상클래스로 정의되었지만 '사용자' 객체를 가지고 접근해야 되는 상황이라고 사료됩니다. 이런 경우에도 상속관계가 맞는건지 아니면 다른 방법을 생각해야 되는건지 조차 햇갈립니다ㅠㅠ
- 0
- 4
- 421
질문&답변
2021.09.30
이런식의 연관관계도 가능한가요?
영한님 먼저 답변 진심으로 감사드립니다.^^ 질문이 정리가 안되고 횡설수설 한것같아 다시 정리해서 질문드립니다 ㅜㅜ @Entity @Inheritance(strategy = InheritanceType.JOINED) @DiscriminatorColumn(name = "DTYPE") public abstract class Item { @Id @GeneratedValue @Column(name = "item_id") private Long id; private String name; private int price; } @Entity @DiscriminatorValue("B") public class Book extends Item { private String author; private String isbn; } @Entity @DiscriminatorValue("A") public class Album extends Item { private String artist; } @Entity @DiscriminatorValue("M") public class Movie extends Item { private String director; private String actor; } 상속 연관관계에서 가장 많은 예시로 사용되는 Item 과 Movie, Album, Book 예시로 질문드립니다 위의 예시에서 각각 Book, Movie, Album의 Repository가 만들어지고 @Repositorypublic interface ItemRepositoryT extends Item> extends JpaRepositoryT, String> {} ItemRepository는 위와 같이 구현 되었다고 볼때 이런식으로 사용될수도 있지만 List bookList = bookRepository.findAll(); List movieList = movieRepository.findAll(); List bookList = albumRepository.findAll(); 아래와 같이 Item으로 받을수도 있는데, 그때 아래와 같이 getClass하거나 instansof를 통해 어떤 자식클래스인지 확인 가능하고 형변환도 가능한것을 확인했습니다. List itemList = itemRepository.findAll(); for(Item item : itemList){ System.out.println(item.getClass().toString()); // Book, Album, Movie 클래스임을 확인. } 질문: 로직상 Book, Album, Movie를 직접 조회할일은 거의 없고Item 만으로 조회해야되는 일이 빈번할 경우는 어떤식으로 로직을 짜야할지모르겠습니다. 시스템입장에선 조회 전에 내가 조회할게 Book인지 Movie인지 모르는 상황이라 Item으로 조회해야만 하는 상황이고 조회 후에 아래 코드 처럼 instanceof를 통해 형변환 해주면 된다 치지만 // 단일 조회일 경우 Item item = itemRepository.findById(id); Book book; if(item instanceof Book){ book = (Book) item; } 단일 조회가 아닌 전체 리스트 조회일경우는 어떤식으로 해야하는지 감이 안잡힙니다 ㅜㅜ // 리스트 조회할경우 ? List itemList = itemRepository.findAll(); for(Item item : itemList){ ??? } 리스트로 조회할때 ORDER BY나 페이징 까지 고려되서 소트된 데이터가 올거라 포문 돌면서 형변환 하고 각각의 리스트에 다시 담기도 어렵고 JPA를 이용해 애초에 받아올때 각각 맞는 클래스에 맞게 받아와서 하나의 리스트에 담는 방법이 없나요?bookList, movieList가 아닌 ItemList 하나만 존재해야 할경우 어떤식으로 해야하나요? List itemList ; ================= 위의 예를 제 상황에 맞게 변경하자면 Item = 사용자 (계정정보) Book = 소방사용자 (소방관련 정보 포함) Movie = 의사사용자 (의사관련 정보 포함) Album = 기타 사용자 (그외 필요 정보 포함) 로 둘수가 있겠죠. 그런데 시스템 로직상 소방사용자만 조회한다던가 의사사용자만 조회한다던가 하는 기능도 있을수 있지만 전체사용자를 계정정보 관련 소트로 불러온뒤 ( Item 리스트를 Item에 해당하는 소트로 불러온뒤) 소방사용자1, 소방사용자2, 의사사용자1, 소방사용자3, 의사사용자2 . ... 이런식으로 불러와야 되기때문에 List 로 불러와야 되기도하고 로그인, 계정정보수정과 같은 공통된 '사용자' 관련 기능들 구현시에도 추상클래스로 정의되었지만 '사용자' 객체를 가지고 접근해야 되는 상황이라고 사료됩니다. 이런 경우에도 상속관계가 맞는건지 아니면 다른 방법을 생각해야 되는건지 조차 햇갈립니다ㅠㅠ
- 0
- 2
- 330
고민있어요
2021.08.18 16:29
ㅋㅋㅋ하스스톤 나올떄마다 너무 재밌음
- 0
- 0
- 136