Spring
3주차가 시작됐다. 3주차 때는 주특기 프레임워크인 Spring을 배우고, 그에 맞는 팀과제와 개인과제가 주어진다. 항해일지를 지금 적는 이유는 3주차 강의를 따라하던 중 예기치 못한 오류에 허덕였기 때문이다.
controller 방식으로 DB와 CRUD를 연결하고 ARC를 통해서 Get, Post, Put, Delete를 실습해보는 강의였다.
결합도를 낮추기 위해서 DTO 방식을 사용해서 CRUD를 진행했는데, 이상하게 ARC에서 Post가 되지 않았다.
오류메시지를 보니
com.fasterxml.jackson.databind.exc.InvalidDefinitionException: Cannot construct instance of com.example.week02.domain.CourseRequestDto (no Creators, like default constructor, exist): cannot deserialize from Object value (no delegate- or property-based Creator)
at [Source: (org.springframework.util.StreamUtils$NonClosingInputStream); line: 2, column: 3]
라고 나오는 것을 보았을 때, DTO에서 생성자를 제대로 찾을 수 없는 것 같아 보였다.
@RequiredArgsConstructor 어노테이션은 파이널 필드의 생성자를 자동으로 생성해주는 것으로 Lombok 라이브러리의 기능이다.
그런데 Lombok이 오류가 난건지 필드에서 final 부분을 지웠을 때는 CRUD가 잘 작동하는데 final를 붙이면 500에러가 노출되었다.
다른 사람들은 문제가 없고, 해당 문제가 발생하는건 나와 내 팀원 한 명 뿐이었다. 결국 final을 지우고 강의를 넘긴 후에 숙제를 위해 다른 프로젝트에서 같은 방법을 사용하니 final을 붙여도 잘 작동을 했다...
솔직히 난 아직도 원인을 모른다.
그냥 해당 프로젝트를 만들 때 Lombok 제대로 설치 되지 않았거나, 내가 못보는 어노테이션 문제일 수도 있다. 솔직히 숙제를 할 때는 문제가 없었기 때문에 나중에 프로젝트를 하다가 해당 문제가 또 발생할지는 모르겠다.
이번 문제를 겪으면서 궁금한 점이 생겼다. 왜 DTO에서 final을 붙이는걸까? DTO와 DI의 차이는 무엇일까? DI는 설명을 들어서 어느정도 알 것 같은데, 점점 배울 수록 모르는 개념들이 많아지고, 특히 왜 사용하는지를 실감하지 못하기 때문에 난감한 경우가 많다.
공부할 것
- final을 왜 붙이는 걸까? (DTO에서)
안붙여도 됐었다! - DTO는 무엇인가? DI와 차이가 무엇인가
DTO는 데이터를 전달하는 것이다. DI랑은 아예 다르다 ㅋㅋ - DTO는 왜 쓰는 것이며 쓰지 않을 경우 어떤 문제가 발생할까?
DTO를 쓰면 장점! 내가 원하는 정보만 API로 줄 수 있다. 이름도 바꿔서 줄 수 있다.
DI
자바의 객체들은 자존심이 쎄다. 다른 객체의 도움을 받는 것을 싫어한다는 뜻이다. 이런 경우를 의존도나 결합도가 높다고 하는데, 예를 들어서 스마트폰 두 개가 있다. 1번 우주폰, 2번 사과폰. 우주폰은 배터리가 분리가 되고, 사과폰은 배터리가 분리되지 않는다. 이 때 배터리가 방전되거나 고장났을 때, 우주폰은 배터리만 교체하면 되지만, 사과폰은 어쩌면 배터리만 교체하는 것이 불가능 하기에 스마트폰 전체를 교체하거나 서비스센터를 가야 하는 상황이 생긴다. 이런 경우 사과폰은 배터리와의 결합도도 높고, 배터리에 의존적이라 할 수 있다.
DI는 의존성 주입으로 번역되는 이 때 이런 생각을 할 수 있다. "아니, 의존성 높으면 안 좋다며! 근데 왜 의존성을 주입해?" 우리가 의존성을 주입해야 하는 이유는 얘네가 자존심이 쎈 애들이라서 서로 도우기 싫어하고, 도움 받기도 싫어하지만 결국 얘네는 스스로 다 할 수 없고 서로의 도움을 받아야 프로그램이 돌아가기 때문에, 억지로 화해를 시켜서 의존성을 주입을 시키는 것이다!
문제!! 근데 왜 오토와이어드쓰고 아래처럼 선언하면 의존도가 낮아지는거죵?
private final ProductService productService;
@Autowired
public ProductController(ProductService productService) {
this.productService = productService;
}IoC
스프링은 다해준다. 지가 알아서 다 해준다. 그래서 나는 스프링의 비서 같은 존재다. 내가 프로그래밍의 주체가 아니라 스프링이 주체다. 지가 알아서 객체도 생성하고, 지가 알아서 값도 넣는다. 얘가 짱이다. 난 노예다.
프로그래밍의 주체가 개발자에서 스프링으로 넘어갔다고 해서 IoC는 제어의 역전으로 번역된다. 이건 정말 개발자로서 자존심이 상하는 일이다. 하지만 어쩔 수 없다. 스프링 없이 서버를 구현하는 것은 내 역량으로는 아직 불가능하기 때문이다. 사실 스프링 없이 서버를 구현하게 될 일이 있을 확률도 현저히 적고, 그러고 싶지도 않다.
결국 스프링이 짱짱이다. 나중에 스프링이 일을 어떻게 하는건지 하나하나 뜯어볼 것이다. 그 전까지 난 스프링의 노예로 걔가 @Service 붙이라고 하면 붙이는거고, repository 만들라고 하면 만드는거다. ㅠㅠ
Bean
이 놈이 내 담당일진이다. 결국 IoC가 가능한건 이 놈이 내가 만든 객체와 클래스를 죄다 가져가서 지가 관리하기 때문이다. 마치 숙제를 뺏기는 것 같다. 얘한테 클래스를 뺏기는 방법은 여러가지가 있다고 하는데, 직접 상납하는게 있고, (xml 같은걸로 설정한다고 한다.)
얘가 하라는대로 셔틀을 하는 방법이 있다. @Component 어노테이션을 붙이는 것이다. 이 경우 얘는 @Component 붙은 애를 골라서 알아서 가져간다. 물론 @Component 어노테이션을 안 붙였다고 방심할 순 없다. @Service @Controller 등 알고보면 @Component가 붙어 있는 애들이 있기 때문이다. (속에 들어가면 보인다) 그럼 이제 빈한테 열심히 만든 클래스를 뺏길 일만 남았다. 걔는 내가 만든 클래스인데 지 혼자 생성하고 값 넣어서 DB랑도 친구먹고, 프론트랑도 친구 먹는다. 나쁜놈이다ㅠ
