픽플 프로젝트에서 update하는 기능들에서 @Setter lombok을 일부러 사용하지 않았었는데, 자잘하게 작성된 함수가 setter기능을 하고 있던 것이었음을 이제서야 알아챘다.

Lombok을 사용해 setter를 자동생성하게 되면 모든 필드들에 대해 외부에서 무분별하게 엔티티의 속성을 바꿀 수 있게 되므로 바람직하지 않다.
필드 하나하나에 대해 setter기능을 하는 함수를 아예 사용하면 안되는건지, 경계가 모호한 것 같아서 견해를 정리하고자 한다.

작성 1. 사용될 필드마다 Setter 작성

Account.java

기본 필드들과 생성자, 아래 함수를 가진 클래스이다.

여기를 작성하면서 어라? 그런데 이거 함수명만 set~이 아닐 뿐이지 setter기능인데, 이렇게 사용해도 되는걸까? 의문을 느꼈다.

AccountUpdateService.java

픽플에서 Account를 Create할 때 Dto를 사용했고,
마찬가지로 Account를 Update할때도 Dto를 사용한다.

1에서는 UpdateDto를 Service층에서 이용하여, 해당 엔티티에 대한 (setter)함수를 사용해 엔티티를 수정했다.

무분별한 setter를 쓰지 않았으니 사실 엔티티(Account.java)를 이렇게 써도 괜찮은 것 아닐까, 라고 생각하며 또 다른 방법을 사용했다.

작성 2. DTO를 Entity층에서 사용

Account.java

기본 엔티티들의 필드와, 생성자와, 아래 함수가 클래스의 멤버로 작성되어 있다.

각각의 모든 필드들에 setter를 두지 않고 필요한 정보만을 DTO를 통해 수정하는것을 목표로 했다.

AccountUpdateService.java

1에서 2로 작성하면서 굉장히 헷갈렸다.
DTO를 엔티티 층에서 저런 방식으로 사용해도 되나? 사실은 서비스 층에서 모든 로직을 처리해야 하는 것 아닌가? 서비스 로직이 저렇게 짧아도 되나?.. 싶었지만 한눈에 잘 들어오긴 했다.

무조건 Setter를 쓰면 안된다! 는 아니라고 생각한다. 다만 최대한 무분별하게 쓰이지 않는 방향으로 아직도 고민을 하고 있지만, 방법 2의 경우 확실히 신경써야하는 점이 많아진다.

실제로 작성2를 토대로 픽플의 모집글을 Update하는 기능을 구현하려고 하니, 모집글은 게시글이라는 엔티티를 상속받는데다가, 필드에 List도 가지고 있어서 굉장히 복잡해졌다!
아직 머리가 정리되지 않아서 그렇게 느끼는 걸 수도 있는 것 같다.

오늘은 여기까지만 작성하고 모집글 부분을 좀 정리한 후에 모집글도 작성2로 다뤄봐야겠다.