해결된 질문
작성
·
257
·
수정됨
0
학습하는 분들께 도움이 되고, 더 좋은 답변을 드릴 수 있도록 질문전에 다음을 꼭 확인해주세요.
1. 강의 내용과 관련된 질문인가요? 예
2. 인프런의 질문 게시판과 자주 하는 질문에 없는 내용인가요? 예
3. 질문 잘하기 메뉴얼을 읽어보셨나요? 예
https://www.inflearn.com/questions/25417/changeteam-%EA%B4%80%EB%A0%A8%ED%95%98%EC%97%AC-%EC%A7%88%EB%AC%B8-%EC%9E%88%EC%8A%B5%EB%8B%88%EB%8B%A4
연관관계 편의 메서드 관련 질문인 위 링크의 글과 연관이 있습니다.
질문을 먼저 작성해놓고 질문 끝에 다시 언급해놓겠습니다.
1) 어쩌면 필요없는 구현일 수 있는데, 이런 습관?을 들여도 괜찮은지
2) 아니면 강의처럼 DB에 반영되지 않고 거의 문제가 발생할 가능성이 없는 부분은 간단하게 구현하고 넘어갈지
mappedBy로 read-only상태인 조회 전용 필드인 members는 변경 상태가 DB에 반영되지 않지만,
인스턴스 입장에서는(객체지향적으로는?) 어플리케이션 런타임 시점에 변경을 해주어야한다고 생각했습니다.
위 링크의 영한님 말씀처럼 데이터 변경 후 이를 즉시 재활용하는 일은 극히 드물지만 말이죠.
Member 엔티티
// 연관관계 편의 메서드
public void changeTeam(Team team) {
// 기존에 팀이 있다면 탈퇴
if (this.team != null) {
// 탈퇴를 위한 비즈니스 로직을 Team에 구현함
this.team.removeMember(this);
}
this.team = team;
team.getMembers().add(this);
}
그래서 위와 같이 if 분기를 두고 소속 팀이 있는 회원은 해당 팀에서 회원 자신을 지우는 로직을 추가했습니다.
this.team.removeMember(this)
위 로직은
this.team.getMembers().remove(this)
와 같지만
의미있는 메서드를 만들어보고 싶어서 아래처럼 removeMember
를 구현했습니다.
Team 엔티티
// 비즈니스 로직 -> read-only 필드라서 DB에는 반영 안됨
public void removeMember(Member member) {
this.members.remove(member);
}
null 확인 로직이 changeTeam()
내부에 있으므로 Member 엔티티 생성자는 다음과 같이 작성했습니다.
public Member(String username, int age, Team team) {
this.username = username;
this.age = age;
changeTeam(team);
}
결론적으로 물어보고 싶은 질문은
1) 어쩌면 필요없는 구현일 수 있는데, 이런 습관?을 들여도 괜찮은지
2) 아니면 강의처럼 DB에 반영되지 않고 거의 문제가 발생할 가능성이 없는 부분은 아래처럼 간단하게 구현하고 넘어갈지
// 연관관계 편의 메서드
public void changeTeam(Team team) {
this.team = team;
team.getMembers().add(this);
}
이렇게 두 가지 질문이 있습니다.
늘 좋은 강의 해주셔서 감사합니다.
답변 2
0
안녕하세요. 강명덕님
이 부분은 선택입니다.
애플리케이션 로직에서 데이터를 처음 세팅하는 단계에서 바로 반대쪽의 데이터를 조회해야 한다면 반드시 필요합니다.
하지만 그렇지 않고, 데이터를 처음 세팅할 때는 단순히 저장만 하고, 이후 JPA에서 조회한 다음에 필요하다면 단순하게 구현하셔도 됩니다.
저의 경우 주로 2번 방법을 선호하고 1번 상황이 필요한 경우에는 1번 방법도 함께 사용합니다.
감사합니다.
0
안녕하세요, 인프런 AI 인턴입니다.
강명덕 님께서 묻고 계신 연관관계 편의 메서드에서 적절한 비즈니스 로직 구현과 관련된 질문인 것으로 보입니다. 이와 관련하여 연관관계를 설정하고 변경하는 로직에 대한 질문들 중 하나로, 객체지향적인 관점에서 DB 반영 여부와 무관하게 인스턴스 상태의 정합성을 유지하는 것이 좋을지, 혹은 DB에 반영되지 않는 부분이면 코드를 간소화할지에 대한 고민이신 것 같습니다.
이에 대해 비슷한 케이스를 다루는 기존의 답변을 여기에 링크로 제공해 드립니다:
changeTeam 관련하여 질문 있습니다. 링크에서는 객체 관점에서 연관관계를 맞추어 주는 것이 올바르나, 실무에서는 보통 데이터 변경 후 즉시 재활용하는 일이 드물어 큰 문제가 되지 않는다는 내용이 담겨 있습니다. 이는 객체의 상태 일관성을 유지하는 것이 이론적으로는 올바르지만, 실제 실무에서는 DB와의 일관성만 보장되면 큰 문제가 되지 않을 수 있는 경우도 있다고 언급되었습니다.
양방향 연관관계에서 관계를 바꿀 때 링크에서는 연관관계 편의 메서드에서 remove 작업시 고려해야 할 점과, 실무에서 맞닥뜨리게 되는 여러 상황들에 대한 논의가 있습니다. 이는 객체 그래프의 일관성이 중요할 수 있음을 시사합니다.
결국, 강명덕 님의 경우와 유사하게 실제로 데이터베이스에 반영되지는 않으나 객체의 상태 일관성을 유지하는 방식으로 구현하는 것과 관련하여 두 가지 관점이 모두 유효하다고 볼 수 있습니다.
객체지향적인 측면에서 상태의 일관성을 유지하는 것은 좋은 습관일 수 있습니다. 특히 향후 복잡한 비즈니스 로직이나 상태를 다루는 경우에 있어서 이러한 일관성이 중요해질 수 있기 때문입니다.
DB에 반영되지 않는 변경에 대해서는 코드를 간소화하여 진행하는 것 또한 선택지 중 하나입니다. 이 방식은 코드의 단순성과 가독성을 높히는 장점이 있으나, 실제로 애플리케이션 내에서 객체를 다룰 때 발생할 수 있는 일관성 문제를 고려해야 한다는 점에 유의해야 합니다.
저는 질문자님의 이해를 돕고자 지식공유자님의 기존 답변을 참고하여 유사한 답변 링크를 추천해드리고 있습니다.
현재 베타 기능으로 답변이 만족스럽지 않을 수 있는 점 양해 부탁드립니다. 🙏
추가적으로 궁금한 점이 있으시면, 이어서 질문해 주세요. 곧 지식공유자께서 답변해 주실 것입니다.