• 카테고리

    질문 & 답변
  • 세부 분야

    백엔드

  • 해결 여부

    미해결

Member 에 orders 를 넣는 구조

23.07.23 20:21 작성 조회수 277

1

Member 객체에서 orders 를 넣는 구조는 좋지 않은 설계라고 하셨는데 여기에 궁금한 점이 있어서 질문합니다! (10분쯤)

 

이커머스 사이트를 볼때, 로그인을 하게 되면 마이페이지가 있고 마이페이지에는 그 회원의 주문내역이나 그동안 주문했던 것들을 볼 수 있는게 꼭 있는거 같습니다.

 

이럴때 Member 에 orders 라는 필드가 있어야 좀 더 효과적으로 가지고 올 수 있다고 생각하는데 영한님께서는 좋지 않은 설계라고 하셔서 제 생각이 틀린건지 궁금합니다!

 

 

답변 1

답변을 작성해보세요.

1

인프런 AI 인턴님의 프로필

인프런 AI 인턴

2023.07.25

안녕하세요, 인프런 AI 인턴이에요. 주신 질문에 답변드리겠습니다.

보통 이커머스 사이트에서는 회원의 주문내역을 확인할 수 있는 기능이 제공됩니다. 회원의 주문내역을 가지고 와서 보여주기 위해 Member 객체에 orders라는 필드를 추가할 수도 있지만, 이는 좋지 않은 설계 방법입니다.

좋은 설계를 위해선 객체 간의 역할과 책임을 명확하게 분리하는 것이 중요합니다. Member 객체는 회원의 정보를 담은 객체로 역할이 명확하게 정해져 있습니다. 반면, 주문내역은 주문에 대한 정보를 담은 객체로 역할이 다른 객체에게 맡겨져 있는 것이 좋은 방법입니다.

대신에, Member 객체와 Orders 객체를 연결하는 방법을 사용할 수 있습니다. Member 객체 내에 orders라는 필드 대신에 Orders 객체를 참조하는 필드를 추가하고, 이를 통해 회원의 주문내역을 조회할 수 있도록 할 수 있습니다. 이렇게 함으로써 역할과 책임을 명확히 분리하고, 객체 간의 의존성 역시 낮출 수 있습니다.

이렇게 설계를 하면, Member 객체에 의존성을 걸어두면 다른 객체에서 회원의 주문내역을 조회하는데 있어서 제약이 생길 수 있습니다. 예를 들어, Orders 객체를 통해 주문내역을 조회하기 위한 복잡한 데이터베이스 쿼리를 작성해야 하는 경우 말이죠. 이와는 달리, Member 객체와 Orders 객체를 분리하면 Orders 객체 내에서 주문내역 조회에 필요한 절차를 간편하게 처리할 수 있습니다.

결론적으로, Member 객체 내에 orders라는 필드를 추가하는 것은 좋은 설계 방법이 아닙니다. 올바른 객체 간의 관계 형성과 역할 분리를 고려하여 설계하는 것이 좋습니다.

더 궁금한 점이 있다면 언제든지 질문해주세요. 감사합니다.