스프링부트에서 User entity를 다룰 때에 @Setter를 쓰지 않는 것이 좋을까요?

Question

&#64;Setter를 쓰지 않는게 좋은 이유에 대해서 많이 구글링해보고 그 결과들이 납득이 되는데깃허브에서 다른 프로젝트들을 열어봤을 때에 유독 회원가입에 관련된 User 엔티티에 대해서는 Setter를 쓰는 것을 많이 보았습니다.어떠한 이유같은 것이 있을까요? 현업에서는 어떤 식으로 사용되는지도 궁금합니다!

Dierslair · Accepted Answer

쓰지 말라는 게 아닌, 외부에서 아무 제약없이 사용할 수 있는 public Setter를 사용할 때에는 주의하라는 의미입니다. Setter가 아예 없으면 PersistenceContext가 DB에서 가져온 값을 Entity에 주입하는 상황에서 예외가 발생할 수 있습니다.(생성자 주입, Reflective Field Access 주입, Setter 주입이 있는데, Setter가 없으면 Setter 주입 사용시 오류)JPA에서 Setter는 곧 Update 쿼리를 의미합니다. Setter를 만들면 해당 Setter가 어디에서든지 호출될 수 있으므로 특정 칼럼이 어디에서 수정되었는지 파악하기 힘들고 칼럼을 수정하기 전 검증이 필요한 경우 이를 무시할 수 있기에 무결성이 훼손되는 등의 부작용이 발생할 수 있습니다.따라서 public Setter를 지양하고 메서드를 별도로 만들어 Update 처리를 OOP스럽게, 통제된 상황에서 쓰는 게 좋다는 의미입니다.대신 Update 처리가 통제된 상황에서는 Setter를 사용해도 무방합니다.예를 들어,&#64;Entity &#64;Setter &#64;Getter public class User { .. &#64;Column(nullable &#61; false) private Integer mileage; // 마일리지(0보다 커야 함) }이 경우 mileage는 어디서든 Setter로 접근하여 수정할 수 있으므로 잘못된 로직 등에 의해 0 미만의 값이 들어가 무결성이 훼손될 수 있습니다.&#64;Entity // &#64;Setter &#64;Getter public class User { .. &#64;Column(nullable &#61; false) &#64;Setter(AccessLevel.PROTECTED) // PersistenceContext가 접근하기 위해 필요 private Integer mileage; // 마일리지(0보다 커야 함) public void consumeMileage(int amount) { // validation if (amount <&#61; 0) { throw new InvalidMileageException(); } if (this.mileage < amount) { throw new MileageInsufficientException(); } this.mileage -&#61; amount; } }Setter 대신 명확히 '마일리지 사용'이라는 의미를 가진 메서드를 만들어 검증 로직을 넣는 경우 가독성도 향상되고 무결성을 유지할 수 있습니다.위 내용은 아주 FM 적인 사항으로 현업에서는 사용하지 않는 경우가 대부분이며(public Setter를 그냥 사용함), 이유로는- 칼럼이 많아질수록 Setter 대신 사용할 메서드가 늘어난다. (엔티티 클래스가 무거워짐) - 어차피 업데이트는 트랜잭션이 있는 서비스 레이어의 특정 메서드에서 수행되며, 그곳에 Validation 로직이 필연적으로 있다. - Validation시 다른 엔티티를 참조하는 경우가 있으면, 엔티티 검증 로직과 다른 엔티티를 참조하는 서비스 검증 로직이 분산된다. 그냥 서비스 레이어에서 검증하고, 단순 Setter를 쓰는 게 코드 파편화를 막을 수 있다. - &#64;Entity 는 DB와 POJO를 연결하는 메타데이터이다. 엔티티는 칼럼 정의와 타 엔티티와의 연관관계 정의 외에는 관심사가 아니다.(경험상 PM이 많이 주장합니다.)등이 있습니다.

ambp · Answer

setter를 쓰지 말라는 건 두 가지 관점입니다.1. 불변객체를 써라2. 가변객체라도 최소한의 필요한 메서드만 노출하라.가변객체보다는 불변객체가 보편적으로 좋은데 jpa dirty check 때문에 가변객체의 장점이 있어요.그런데 무지성 setter를 쓰는 건 좋은 건 아닙니다.

chytonpide · Answer

스타일이나, 설계 관점에 따라 다를 수 있지만 한 프로젝트에서 User엔티티에만 setter를 쓰는 경우 라면 특별한 이유가 있다기 보다는 스타일이나 설계의 일관성을 지키지 못하고 있는게 아닐까요? 저는 public setter 사용을 선호하지 않습니다. private setter 메서드를 사용하고 각각의 setter 메서드는 가드 역할을 합니다. JPA를 사용하는 경우 &#64;Access(AccessType.FIELD) 를 사용해서 public setter없이 매핑이 되도록합니다.&#64;Accessors(fluent &#61; true) &#64;Getter &#64;NoArgsConstructor(force &#61; true, access &#61; AccessLevel.PRIVATE) &#64;Table(name &#61; &#34;user&#34;) &#64;Entity &#64;Access(AccessType.FIELD) public class User { ... } entity를 단순한 데이터로 볼지, 객체로 볼지에 따라 다르지만 저는 불변식을 가지는 객체로 보고, 아래 처럼 setter대신에 조금 더 풍부한 메서드 이름을 사용합니다. user.changeConntactInfo(contactInfo); user.changeName(name); user.changePassword(currentPassword, newPassword); user.activate(); user.deactivate();

1234341431 · Answer

세분 다 너무 감사드립니다 정확히 언제 어떻게 setter를 쓰라는건지 확실히 알 것같습니다!!!

스프링부트에서 User entity를 다룰 때에 @Setter를 쓰지 않는 것이 좋을까요?

4개의 답변

Q&A 목록