인프런 커뮤니티 질문&답변
작성한 질문수
단방향 설정이 가능한지 궁금합니다!
작성
·
246
답변 1
1
안녕하세요. 양양이님
정확하게 질문을 이해했는지 모르겠습니다!
제가 잘못 이해한 것이라면 질문 내용이 포함된 강의 시간대나 예시와 함께 알려주시면 감사하겠습니다!
Order N:1 Member => 다대일 단방향이 가능한지
=> 가능합니다. 결국 단방향, 양방향 설정은 요구사항에 따라 개발자가 어떻게 구현할 것인지에 따라 달라진다고 생각합니다. 만약 Order만 주로 조회하고 반대로 Member에서는 Order 목록을 가져올 일이 없다고 하면 굳이 Member에서는 연관관계를 걸어줄 필요가 없습니다.
OrderItem N:1 Order => 다대일 단방향이 가능한지
=> 이 부분은 약간 다르다고 생각합니다. 저희는 Order와 Item을 다대다 관계로 매핑하기로 요구사항에 따라 결정했습니다. 이에 따라 OrderItem은 중간의 매핑 테이블로서 형성한 것이고, 결국 비즈니스 로직에서 사용할 때는 Order를 기준으로 많이 조회해올 것을 예상할 수 있습니다. 이런 상황이라면 양방향 연관관계를 걸어서 해주는 것이 맞다고 생각합니다!
Order와 Delivery 관계에서 단방향이 안되는 이유
=> 요구사항에 따라 달라질 수는 있으나 일대일 단방향 관계를 할 수 있습니다. 외래키를 갖고 있는 곳(주로 같이 조회할 곳)을 기준으로 단방향을 걸어주고 반대 방향에서의 조회는 요구사항 상 잘 사용하지 않는다면 단방향이 가능합니다.
Item과 Category를 일대다, 다대일로 풀어내는게 맞는지
=> 이 또한 다대다 관계에 해당하고 보여주기 위해 @ManyToMany로 표현해준 것이라 영한님께서 말씀해주신 것처럼 Order - OrderItem - Item 의 케이스와 같이 일대다, 다대일 관계로 풀어내시는게 맞을 것 같습니다!
감사합니다.
저는 보통 요구사항을 보고 구현해야할 것을 생각합니다. 이번에는 강의의 ERD, API 등을 보고 유추했습니다. 이 과정에서 주체를 설정하는 것 같습니다.
예를 들어 이번 강의에서는 간단한 이커머스 플랫폼에 대한 요구사항을 바탕으로 ERD를 작성했습니다. 그에 따라 API의 성격들도 일반 사용자를 대상으로 만드는 것이 많을 것입니다. 이러한 판단을 기반으로 Order와 Item 을 바라봤을 때, 일반 사용자 입장에서는 Item보다는 Order를 기준으로 조회한 결과를 받는 경우가 대다수일 것이라 생각하고 설계할 수 있을 것 같습니다!
참고: 회원이 주문을 하기 때문에, 회원이 주문리스트를 가지는 것은 얼핏 보면 잘 설계한 것 같지만, 객체 세상은 실제 세계와는 다르다. 실무에서는 회원이 주문을 참조하지 않고, 주문이 회원을 참조하는 것으로 충분하다. 여기서는 일대다, 다대일의 양방향 연관관계를 설명하기 위해서 추가했다.
강의자료 회원 엔티티 분석 마지막에 위와 같이 쓰여있는데
" 회원이 주문을 하기 때문에, 회원이 주문리스트를 가지는 것은 얼핏 보면 잘 설계한 것 같지만" -> 이 문장은 사용자 관점이 맞나요?
"객체 세상은 실제 세계와는 다르다." -> 이 문장에서 말하는 객체 세상과 실제 세계는 구체적으로 어떤 차이가 있는건가요?
실제 세계 = 사용자 관점
객체 세상 = 서버 관점, 실무
-> 이렇게 정리해서 알고있으면 될까요??
또한, '비즈니스 로직'이란 말은 둘 중에 어디에 속하는지 궁금하고, 엔티티 방향 설정 시 객체 세상을 기준으로 설계하는게 맞는지 궁금합니다!
" 회원이 주문을 하기 때문에, 회원이 주문리스트를 가지는 것은 얼핏 보면 잘 설계한 것 같지만" -> 이 문장은 사용자 관점이 맞나요?
이 시점에서는 사용자 관점이 아닌 이미 만들어져있는 요구사항을 보고 설계를 시작하는 개발자의 관점이라 생각합니다.
"객체 세상은 실제 세계와는 다르다." -> 이 문장에서 말하는 객체 세상과 실제 세계는 구체적으로 어떤 차이가 있는건가요?
=> 예를 들어 실제 세계에서 수동적인 객체가 객체 세상에서 소프트웨어적인 객체가 됐을 때를 생각해볼 수 있을 것 같습니다. 딱 맞는 예시라고 생각하진 않지만 Order 또한 실제 세계에서는 수동적인 객체입니다. 하지만 우리의 객체 세상에서는 스스로 주문 아이템을 만들고 있습니다.
요구사항 정의한 경험이 그리 많지는 않으나, 요구사항을 만들 때는 해당 애플리케이션을 사용하는 사용자(사용자는 애플리케이션의 용도에 따라 다를 것 같습니다. 예를 들어 어드민 애플리케이션이라면 아마 회사 다른 팀 동료가 사용자가 될 것입니다.)의 관점으로 생각해서 정의하는 것 같습니다.
그리고 해당 요구사항을 바탕으로 설계할 때는 이미 요구사항에 사용자의 관점은 내포되어있으니, 실제 개발에서의 트레이드 오프를 따져 구현해내는 것이라 생각합니다.
저도 실무 경험이 그리 많지 않은 개발자라 속시원히 대답을 드리지 못해 죄송합니다.
답변 감사합니다!
궁금한점이 있습니다.
"Order만 주로 조회하고 반대로 Member에서는 Order 목록을 가져올 일이 없다고 하면",
"결국 비즈니스 로직에서 사용할 때는 Order를 기준으로 많이 조회해올 것을 예상할 수 있습니다."
"외래키를 갖고 있는 곳(주로 같이 조회할 곳)을 기준으로 단방향을 걸어주고 반대 방향에서의 조회는 요구사항 상 잘 사용하지 않는다면 단방향이 가능합니다."
이와 같은 문장에서 주체를 무엇으로 생각하는게 좋은가요??