좋은 내용 감사합니다. 엔티티를 불변객체로 다루면 JPA 사용시 더티 체킹을 사용할 수 없어서 어쩔 수 없이 변경가능하도록 사용하는건가요? 영상 질문 내용에 2번처럼 불변객체에 Copy 메써드를 통해 데이터를 변경하도록 사용하는게 좋아보이는데, 별도로 save메써드로 엔티티 변경사항을 DB에 반영해야 한다는 것이 고민되긴 하네요..
안녕하세요 태윤님!! 말씀해주신 것처럼 더티 체킹이 어려워 save를 호출해주는 것이 번거로운 측면도 있고, 객체를 새로 복사한다는 것 자체가 연산 비용이라는 측면도 있습니다! 이게 API에서 Entity 단건만을 복사하면 상관이 없지만 1) 그 API가 초당 수천번씩 호출되는 API이거나 2) 애당초 수백/수천만건씩 한번에 업데이트 해야 하는 경우는 객체를 복사하는 연산 비용이 꽤 클 것이라고 생각합니다! (물론 정확히는 측정 해보아야 알지만요!) 그렇다고 여러 방법을 혼용해서 사용하자니, 여러 방법들을 섞어 사용하는 혼란이 있을거라 차라리 저는 setter를 여는 방법으로 통일한 것입니다 ㅎㅎㅎ 이 방법을 사용했을 때 setter를 열어둬서 생기는 혼란은 2년 가까이 한 번도 없었어요!! (setter를 쓰면 안된다가 워낙 강하게 자리 잡혀서 그런 것 같습니다! 마치 변수 이름에 camelCase를 써야하는 것처럼요 ㅎㅎㅎ) 당연히 사람마다 의견이 다를 수 있고, 컨벤션만 잘 맞추면 된다고 생각합니다!!
좋은 내용 감사합니다.
엔티티를 불변객체로 다루면 JPA 사용시 더티 체킹을 사용할 수 없어서 어쩔 수 없이 변경가능하도록 사용하는건가요?
영상 질문 내용에 2번처럼 불변객체에 Copy 메써드를 통해 데이터를 변경하도록 사용하는게 좋아보이는데,
별도로 save메써드로 엔티티 변경사항을 DB에 반영해야 한다는 것이 고민되긴 하네요..
안녕하세요 태윤님!!
말씀해주신 것처럼 더티 체킹이 어려워 save를 호출해주는 것이 번거로운 측면도 있고, 객체를 새로 복사한다는 것 자체가 연산 비용이라는 측면도 있습니다!
이게 API에서 Entity 단건만을 복사하면 상관이 없지만 1) 그 API가 초당 수천번씩 호출되는 API이거나 2) 애당초 수백/수천만건씩 한번에 업데이트 해야 하는 경우는 객체를 복사하는 연산 비용이 꽤 클 것이라고 생각합니다! (물론 정확히는 측정 해보아야 알지만요!)
그렇다고 여러 방법을 혼용해서 사용하자니, 여러 방법들을 섞어 사용하는 혼란이 있을거라 차라리 저는 setter를 여는 방법으로 통일한 것입니다 ㅎㅎㅎ
이 방법을 사용했을 때 setter를 열어둬서 생기는 혼란은 2년 가까이 한 번도 없었어요!! (setter를 쓰면 안된다가 워낙 강하게 자리 잡혀서 그런 것 같습니다! 마치 변수 이름에 camelCase를 써야하는 것처럼요 ㅎㅎㅎ)
당연히 사람마다 의견이 다를 수 있고, 컨벤션만 잘 맞추면 된다고 생각합니다!!