항해99 5주차 WIL - API

벌써 5주차가 지났다. 이번 주는 프론트엔드는 건들이지 않고 API만 만드는 과제를 수행했다.

 

request 의 조건이 맞는 지 확인하는 로직을 작성하고 맞지 않는 다면 에러를 발생시키는 서비스 로직이 많았다. 이러한 조건을 하나하나 if 문으로 작성하여 service에서 작성하니 코드가 너무 방대해지고 구독성이 떨어져서 validate하는 클래스로 따로 작성해서 리팩토링하며 역할에 따른 클래스 나누기의 중요성을 느꼈던 것 같다. 

 

POST, GET할 때 request와 response가 달라 DB에 어떻게 저장하고 받아올 수 있을 까 고민을 많이 했다.

이전 과제에서는 Controller에서 바로 repository에서 entity 형태로 DB에서 response 하도록 작성했는데 MVC 패턴을 꼭 지키기 위해서 Controller에서는 오직 service만 접근할 수 있도록 해야했다.

 

request 받은 데이터를 DB에 저장하기 위해서는 entity로 변환해주는 작업이 필요했다. 그리고 repository를 통해 받은 데이터는 entity형태이기 때문에 dto형태로 변환시켜 return해줘야 한다. 이 작업에서 꽤나 애먹었다... 끝없는 에러와 싸우던 도중 다른 팀의 고수분의 조언을 받고 모두 request 와 response 모두 DTO를 만들어서 작성해야한다는 것을 알게 되었다.

 

근데 entity에서 필요한 값만 추출해서 return해줘도 될 것 같은데 왜 굳이 dto로 다시 변환해줘야 하는지 궁금했다.

Entity는 데이터의 테이블이라고 생각하면 된다.

Entity로 return 해줄 경우 서비스 단은 데이터와 독립적이야 하는데 데이터의 변경사항이 있으면 Entity를 사용하는 서비스단에도 영향이 미친다.

 

그래서 데이터를 주고 받을 때는 DTO를 만들어서 사용해야 한다. (DTO는 데이터 전달용 객체라고 생각하면 된다...) 구글링한 결과 많이 데이터 교환이 이루어지는 대규모 프로젝트에서는 DTO가 필수이지만 작은 사이즈의 프로젝트에는 굳이 필요없다는 의견도 많았다. 하지만 

DTO를 쓰면 

 

1. 도메인과 프레젠테이션 분리

2. 데이터 교환 overload 감소(DTO 본 목적)

3. 인터페이스, API 안전성

 

등의 장점이 있다고 한다.

 

그래서 앞으로 DTO를 많이 만들어서 DB와 통신하는 연습을 많이 해야할 것 같다.

DTO와 Entity 를 서로 변환하는 과정이 어려웠기 때문에 해보면서 익혀야 할 것 같다. 이 과정을 편하게 할 수 있는 라이브러리도 있다고 하니 다음 프로젝트에서는 한 번 활용을 해봐야 겠다.

 

*이번 과제에서는 처음에 생성자로 전부 작성했는데 인자 순서를 잘못 넣어서 오류가 났는데 디버깅 하는 데 매우 힘들었다.. 분명 다른 방식이 있을 거라고 생각하고 구글링 했더니 객체를 다시 만들 때는 생성자 대신 builder 패턴을 이용해서 내가 겪었던 그런 문제점을 보완할 수 있다고 하여 리팩토링 하면서 builder 를 사용해보았는데 Lombok 덕분에 builder패턴을 아주 손쉽게 할 수 있었다. 앞으로는 객체 생성 시 builder패턴을 애용할 것 같다. 

 

빌더 패턴(Builder Pattern) 만들기 + Lombok이용

* JPA를 본격적으로 사용하면서 테이블끼리 mapping할 일이 많았는데 관계 설정을 잘 못해서 무한 호출되는 에러가 발생해서 디버깅하는데 고난이 있었다...

다음 주는 JPA 관계설정에 대해서 자세히 공부하는 시간을 가질 예정이다. 

 

👍 이번 주 keyword

 

❓같이 일하기 좋은 개발자란?

  

  이번 주 keyword를 받고 생각나는 한가지가 있었다.

바로 지식공유를 잘하는 개발자이다. 항해를 하면서 질문을 했을 때 도움을 주시는 팀원분들을 많이 만났다. 이야기를 해보면 정말 본인이 잘 알고 있고 배경지식이 풍부하셔서 정답 뿐만 아니라 왜 그래야하는지 나같은 초보자도 이해할 수 있도록 맞춤 교육을 해주시는 분들이 계시다. 그런 분들을 볼 때마다 더 열심히 해야겠다는 자극제도 될 뿐만 아니라 공부 방법같은 걸 많이 배울 수 있는 것 같다. 매번 물어보기 미안해서 조심스럽게 질문 드리는데 항상 양질의 대답과 긍정적인 태도로 도와주셔서 나도 개발자로 일하면 저런 개발자가 되어야겠다는 생각을 했다. 좋은 에너지를 받는 것 같다.

 

 처음 개발 공부를 시작해서 놀란 부분은 공유 문화가 매우 활발하다는 점이었다. 자신의 지식을 공유하는 블로그도 많고 무료 강의, 커뮤니티 활동, 오픈소스 등등 폐쇄적인 공부를 해온 나로써는 굉장히 놀라웠다.

블로그를 쓰면서 살짝 아는 지식을 글로 쓴다는 것은 무척이나 어려웠다. 내가 정확히 알고 있어야 비로소 글을 쓸 수 있었고, 이 글을 남이 본다고 생각하니 잘못된 정보를 적을 까 무척이나 조심스러웠다. 혼자보는 공간에 나만 알아볼 수 있게 정리하는 것과는 비교할 수 없을 정도의 시간과 노력이 들어가는 일이었다. 이런 어려운 행동을 많은 개발자들이 꾸준히 하고 있기 때문에 상향평준화되고 있지 않나하는 생각이 들었다. 

 

◆ Singleton pattern

소프트웨어 디자인패턴 중 하나로, 객체의 인스턴스가 오직 1개만 생성되는 패턴을 의미한다.

매번 필요시 마다 새로 만들어서 쓰지 말고 최초 한 번만 만들어서 메모리에 저장해 놓고 공유해서 쓰자는 의미로 받아들이면 될 것 같다.

 

사용하는 이유?

* 메모리 측면

  매번 객체를 만들 때마다 메모리를 사용하니깐 메모리 낭비가 있다. 미리 하나 만들어 놓고 가져다 쓰면 메모리가 낭비되지 않을 수 있다. 

 

스프링에서는 싱글톤 패턴을 구현하지 않아도 스프링 컨테이너가 객체 인스턴스를 싱글톤으로 관리하고 있다. 

애플리케이션이 시작 될 때 특정 어노테이션이 붙어있는 클래스를 컴포넌트 스캔하여 Bean으로 스프링 컨테이너에 담아 메모리에 올린다.

 

@Controller, @RestController, @Service, @Repository, @Component 등등...

 

오직 한 개만 Bean으로 등록되기 때문에 싱글톤 패턴이라고 할 수 있다. 

필요할 때는 만들지 말고 불러서 쓰면 된다.(그것이 DI....)

 

◆POJO

 

POJO란??