1. DTO 클래스를 생성하고 setter를 열지 않고 생성자 주입 방식으로 구현해 봅니다.
과거 김영한의 춘계강연 때 “절대 세터를 열면 안 된다”는 문구가 떠돌았다.
디자이너로서 저는 그것을 어떻게든 구현하기 위해 고집이 아니라 고집이 되었습니다.
결과적으로 내 고집은 거대한 삽이었고, 답을 찾기 위해 열심히 찾고 또 찾았는데…
그렇게 오랫동안 검색한 끝에 Infron QnA에서 DTO가 세터를 열어야 하는지에 대한 질문을 발견했습니다.
이에 영한은 세터는 가급적 적게 쓰는 게 낫다고 말했다.
하지만 DTO의 경우 로직이 없었기 때문에 단순 데이터 전송이기 때문에 자유롭게 사용할 수 있다는 답변이 나왔습니다.
요약하다
DTO 자체는 로직이 없고 단순한 데이터 전송이 목적 => Setter 사용 가능
엔터티는 논리가 있고 실제 데이터를 변경할 수 있으므로 최대한 Setter X를 사용하십시오.
필요한 경우 별도의 메서드를 만드는 것이 좋습니다.
나는 이것을 얻으려고 몇 시간을 낭비했다
그래도 삽질하던 그 시간에 뭔가를 깨닫고 이겨서 다행이다.
오늘 내가 한 삽질은 헛되지 않았다.
관련된 링크들
DTO 사용에 관심이 있습니다. – 인프라 | 질문 및 답변(inflearn.com)
2. JPA 매핑 오류
데이터베이스에 대해 잘 모르겠습니다.
전 직장에서 우연히 오라클 데이터베이스를 접하고 사용했지만,
아직 적응이 안되고 늘 부족함을 느꼈습니다.
아침에 다시 영한의 JPA talk를 반복하며 자신감을 얻었다.
그냥 Visual Studio Code를 켜고 db를 디자인하면서 빠르게 코딩을 하고 싶다는 생각이 들었습니다.
설계를 완료한 후 IntelliJ를 켜고 몇 가지 기본 JPA 개발을 시도했습니다.
낯설고 낯설었던 처음과 달리 순조롭게 흘러갔다.
자신감이 급상승하면서…
프로그래밍을 마치고 서버가 잘 돌아가는지 확인했다.
JPA 엔터티 측에서 매핑 매핑이 잘못된 오류가 발생했습니다.
확실히 맞췄는데 뭐가 잘못된건지 몰라서 미친듯이 구글링 했습니다.
검색도 안되네요…
먼저 코드를 무작위로 수정하기 위해 열심히 노력했습니다.
많은 시행착오 끝에 서버가 정상으로 돌아왔습니다.
코드를 수정한 후 다시 검색했습니다.
그제서야 내가 뭘 잘못 코딩했는지 깨달았다.
아침에 데이터베이스를 설계하면서 “히히 재미있다. 나는 개발자 천국인 것 같다”고 생각했다.
즐겁게 작업했는데, 코딩하다가 몇 가지 오류를 만나면 금방 좌절한 경험이 있습니다.
어쩌면 그것이 우리 삶의 축소판이 아닐까 생각합니다.
다음에는 이런 실수를 하지 않도록 블로그에 쓰려고 노력했습니다.
글을 쓰는 동안 오류가 발생하여 두통을 유발하는 이야기를 방금 해결했습니다.
앞으로 같은 오류가 반복되지 않기를 바랍니다.