ManyToMany 연관 관계에서 엔티티 삭제

배경

<aside> 🚨

계획 테이블과 참여자 테이블은 N:M 관계를 가지며, 이것이 Spring Jpa에서 ManyToMany로 의도적으로 작성된 상황이다.

</aside>

원인

<aside> 🔥

두 엔티티는 양방향 참조가 가능한데, Cascade 옵션이나 orphanRemoval 등의 옵션을 사용하지 못하기 때문에, Row 삭제 시 관련한 참조 삭제가 자동적으로 이뤄질 수 없어 서비스 오류가 발생한다.

</aside>

조치

<aside> 🚧

한 쪽의 엔티티를 삭제할 때, 확실하게 두 엔티티의 참조 관계를 제거하는 단위 로직을 직접 작성하여 서비스에서 동작시켰다.

</aside>

대처

<aside> 🛠

JPA에서 편리하게 사용할 수 있는 참조 관계는 연관 기능을 적절히 사용하되, 특수한 경우에는 연관 관계에 의존하기보다는 직접 로직을 작성하는 것으로 결정하였다.

</aside>

결론

<aside> ✅

ManyToMany는 물론이고, FK 및 Cascade 방식 자체가 제법 단점이 될 수 있는 경우가 꽤 있음을 명심해야겠다.

</aside>

무분별한 멤버 메서드 사용 문제

배경

<aside> 🚨

두 가지 케이스가 해당된다. 첫 번째는, 주로 POST 메서드에 대한 요청 Dto를 곧바로 생성하고자 하는 Entity 로 변환을 하는 과정에서, 해당 Entity의 생성자를 사용하지 않기 위해 Dto에서 toEntity() 등의 멤버 메서드를 정의하는 것이다. 두 번째는, 서비스 로직에서 사용자 id와 게시글 id 등에 대해 repository를 통해 조회하고, 조회한 내용이 null 이 아닌지 확인하고, 사용자와 게시글의 연결 여부를 확인하고… 등등, 반복적인 작업을 해당 서비스 클래스의 멤버 메서드로 정의하는 것이다.

</aside>

원인

<aside> 🔥

첫 번째 Case에서, 요청 Dto 클래스에서 엔티티를 생성하는 것은 엔티티 입장에서는 Dto를 포함하지 않기 때문에 좋은 개선사항이지만, 개인적으로 엔티티 생성에 추가적인 로직이 들어가거나 할 때마다 단순한 Dto 에 그러한 책임을 포함시키는 것이 조금 불편했다. 두 번째 Case에서, 서비스 로직에서 반복되는 작업을 멤버 메서드로 정의하는 것은 사실 당장 생산성과 가독성 측면에서 제법 괜찮은 방법이지만, 이러한 방식을 반복적으로 사용한다면 결국 서비스 로직이 지나치게 복잡해지고, 서로 다른 서비스에서 비슷한 작업을 반복할 때에 대한 고려가 부족하다는 문제가 느껴졌다.

</aside>

조치